Method of Managing Workloads and Associated Distributed Processing System

ABSTRACT

Various embodiments enable a server system to receive a request to store data, select various distributed devices to store the data, and then send the data to the selected distributed devices. In one embodiment, a method may include: receiving a request to store back-up data on a distributed processing system from a client system, the back-up data having a storage priority, searching a database to identify one or more distributed devices with excess storage capacity, and selecting one or more of the distributed devices to store the back-up data based in part on the back-up data&#39;s storage priority. Then, sending the back-up data to one or more selected distributed devices along with retention instructions indicating conditions for retaining and/or deleting the back-up data, and updating an index with addresses for the one or more selected distributed devices that received the back-up data.

REFERENCE TO EARLIER APPLICATIONS

This is a continuation of and claims priority to U.S. patent applicationSer. No. 09/794,969, entitled “System and Method for Monetizing NetworkConnected User Bases Utilizing Distributed Processing Systems,” filed onFeb. 27, 2001, which is incorporated by reference.

This application is a continuation-in-part application of and claimspriority to the following applications: U.S. Pat. No. 6,654,783 entitled“System and Method for Monetizing Network Connected user Bases UtilizingDistributed Processing Systems;” U.S. Pat. No. 6,891,802 entitled“Network Site Testing Method and Associated System;” U.S. patentapplication Ser. No. 09/539,023 entitled “Sweepstakes Incentive Modeland Associated System;” U.S. patent application Ser. No. 09/539,448entitled “Capability Based Distributed Parallel Processing System andAssociated Method;” U.S. patent application Ser. No. 09/539,428 entitled“Method of Managing Distributed Workloads and Associated System;” U.S.patent application Ser. No. 09/539,107 entitled “Distributed BackupSystem and Associated Method;” and U.S. patent application Ser. No.09/603,740 entitled “Method of Managing Workloads and AssociatedDistributed Processing System;” each of which was filed on Mar. 30, 2000and each of which is incorporated by reference.

This application is also a continuation-in-part of and claims priorityto the following: U.S. Pat. No. 7,020,678 entitled “Machine GeneratedSweepstakes Entry Model and Associated Distributed Processing System;”U.S. Pat. No. 6,963,897 entitled “Machine Generated Sweepstakes EntryModel and Associated Distributed Processing System;” and U.S. patentapplication Ser. No. 09/602,844 entitled “Data Conversion Services forAssociated Distributed Processing System;” each of which was filed onJun. 23, 2000 and each of which is incorporated by reference.

BACKGROUND

A number of traditional Internet-focused businesses have based theirability to monetize users via an advertising model. Given the currentdecline in rates for web page banner advertising, as well as rates forother web page advertising forms, these businesses are often unable todevelop and implement sustainable business models that lead toprofitability. In many cases, these Internet-focused businesses providea service in exchange for advertising exposure which their users arewilling to allow because they value the service being offered.Unfortunately, most of these business face revenue rates (e.g.,advertising rates) that are declining faster than their costs (e.g.,cost of services provided to users).

SUMMARY

This Summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This Summary is not intended to identify key features oressential features of the subject matter, nor is it intended to be usedto limit the scope of the subject matter.

Various embodiments enable a server system to receive a request to storedata, select various distributed devices to store the data, and thensend the data to the selected distributed devices.

In at least one embodiment, a method of operating a distributedprocessing system may include receiving a request to store back-up dataon a distributed processing system, searching a database to identify oneor more distributed devices with excess storage capacity, selecting oneor more of the distributed devices to store the back-up data based inpart on the back-up data's storage priority, sending the back-up data toone or more selected distributed devices along with instructions forretaining and/or deleting the back-up data, and updating an index withaddresses for the one or more distributed devices that received theback-up data.

In a further embodiment, a computer readable storage media may includeinstructions to receive a command from a user to store data, prompt theuser to select one or more options for storing the data, generate astorage priority for the data based in part on the storage optionsselected by the user, request a server system to store the data, andsend the data to the server system for distribution and storage on oneor more distributed storage devices.

BRIEF DESCRIPTION OF THE DRAWINGS

The same numbers are used throughout the drawings to reference likefeatures.

FIG. 1A is a block diagram for a distributed processing system havingclient capability and incentive features, according to one or moreembodiments.

FIG. 1B is a block diagram for information flow among customer systems,server systems and client systems, according to one or more embodiments.

FIG. 2A is a block diagram for a client system, according to one or moreembodiments.

FIG. 2B is a block diagram for processing elements within a clientsystem, according to one or more embodiments.

FIG. 2C is a block diagram for a client system agent installed on aclient system, according to one or more embodiments.

FIG. 2D is an example user interface for a client system agent,including incentive advertising, according to one or more embodiments.

FIG. 3A is a block diagram for server systems, according to one or moreembodiments, including a control system, a sweepstakes system and aworkload database.

FIG. 3B is a block diagram for servers systems, customer systems, clientsystems and outsourced host systems, according to one or moreembodiments.

FIG. 3C is a block diagram for a server system processor, according toone or more embodiments.

FIG. 3D is an alternative block diagram for a server system processor,according to one or more embodiments.

FIG. 4 is a functional block diagram for an example sweepstakesincentive operation according to one or more embodiments.

FIG. 5A is a block diagram for a distributed processing system for anetwork site indexing application, according to one or more embodiments.

FIG. 5B is a functional block diagram for an indexing operationaccording to one or more embodiments.

FIG. 6A is a block diagram for a server system according to one or moreembodiments, including a control system, a workload database, and adatabase of client capabilities balancing vectors.

FIG. 6B is a functional block diagram for client capabilities balancingof workloads according to one or more embodiments.

FIG. 7A is a block diagram for a distributed processing system,according to one or more embodiments, including example network sites onwhich site testing is to be conducted, such as load testing and/orquality-of-service testing.

FIG. 7B is a functional block diagram for site-testing, according to oneor more embodiments.

FIG. 8 is a block diagram of a distributed processing system for a databackup application, according to one or more embodiments.

FIG. 9 is a block diagram of an alternative representation of aninterconnection fabric for a distributed processing system environment,according to one or more embodiments.

FIG. 10 is a block diagram of a more detailed block diagram for a clientsystem agent installed on a client system, according to one or moreembodiments.

FIG. 11A is a more detailed flow diagram for machine generatedsweepstakes entries according to one or more embodiments.

FIG. 11B is an alternative detailed flow diagram for machine generatedsweepstakes entries according to one or more embodiments.

FIG. 12A is a block diagram of a distributed processing system thatallows customers to select client system attributes, according to one ormore embodiments.

FIG. 12B is a block flow diagram for client system attribute selection,according to one or more embodiments.

FIG. 13A is a block diagram of a distributed processing system thatprovides data conversion services, according to one or more embodiments.

FIG. 13B is a block flow diagram for data conversion services within adistributed processing system, according to one or more embodiments.

FIG. 14A is a block diagram of a distributed processing system thatprovides data transmission caching, according to one or moreembodiments.

FIG. 14B is a block diagram of a distributed processing system thatprovides data sharing and file distribution, according to one or moreembodiments.

FIG. 15 is a block diagram of an alternative representation for adistributed processing system, according to one or more embodiments.

FIG. 16 is a block diagram of a representation for a distributedprocessing system including security subsystems, according to one ormore embodiments.

FIG. 17A is a block diagram of a client system and server systemscommunication interface, according to one or more embodiments.

FIG. 17B is a block diagram of communication layers for client systemand server systems communication, according to one or more embodiments.

FIG. 18A is a detailed block diagram for an embodiment of securityactivities for server systems.

FIG. 18B is a detailed block diagram for an embodiment of securityactivities for client systems.

FIG. 19 is a block diagram for a distributed processing system andenvironment in which network service providers are enabled to monetizetheir user bases in accordance with one or more embodiments.

FIG. 20 is a block diagram representing the components for a clientagent along with a representative indication of responsibility for thosecomponents in accordance with one or more embodiments.

DETAILED DESCRIPTION

The present embodiments contemplate the identification of thecapabilities of distributed devices connected together through a widevariety of communication systems and networks and the aggregation ofthese capabilities to accomplish processing, storage, broadcasting orany other desired project objective. For example, distributed devicesconnected to each other through the Internet, an intranet network, awireless network, home networks, or any other network may provide any ofa number of useful capabilities to third parties once their respectivecapabilities are identified, organized, and managed for a desired task.These distributed devices may be connected personal computer systems(PCs), internet appliances, notebook computers, servers, storagedevices, network attached storage (NAS) devices, wireless devices,hand-held devices, or any other computing device that has usefulcapabilities and is connected to a network in any manner. Variousembodiments further contemplate providing an incentive, which may bebased in part upon capabilities of the distributed devices, to encourageusers and owners of the distributed devices to allow the capabilities ofthe distributed devices to be utilized in the distributed parallelprocessing system of the present embodiments.

The number of usable distributed devices contemplated by variousembodiments can be very large. Unlike a small local network environment,for example, as may be used by an Internet Service Provider (ISP), whichmay include less than 100 interconnected computers systems to performthe tasks required by the ISP, the various embodiments can utilize amultitude of widely distributed devices to provide a massivelydistributed processing system. With respect to the various embodiments,a multitude of distributed devices refers to greater than 1,000different distributed devices. With respect to the various embodiments,widely distributed devices refer to a group of interconnected devices ofwhich at least two are physically located at least 100 miles apart. Withrespect to the various embodiments, a massively distributed processingsystem is one that utilizes a multitude of widely distributed devices.The Internet is an example of a interconnected system that includes amultitude of widely distributed devices. An intranet system at a largecorporation is an example of an interconnected system that includesmultitude of distributed devices, and if multiple corporate sites areinvolved, may include a multitude of widely distributed devices. Adistributed processing system according to the various embodiments thatutilize such a multitude of widely distributed devices, as are availableon the Internet or in a large corporate intranet, is a massivelydistributed processing system according to the various embodiments.

FIG. 1A is a block diagram for a distributed parallel processing system100 according to at least some embodiments. The network 102 is shownhaving a cloud outline to indicate the unlimited and widely varyingnature of the network and of attached client types. For example, thenetwork 102 may be the Internet, an internal company intranet, a localarea network (LAN), a wide area network (WAN), a wireless network, ahome network or any other system that connects together multiple systemsand devices. In addition, network 102 may include any of these types ofconnectivity systems by themselves or in combination, for example,computer systems on a company intranet connected to computer systems onthe Internet.

FIG. 1A also shows client systems 108, 110 . . . 112 connected to thenetwork 102 through communication links 118, 120 . . . 122,respectively. In addition, server systems 104, other systems 106, andcustomer systems 152 are connected to the network 102 throughcommunication links 114, 116 and 119, respectively. The client systemcapabilities block 124 is a subset of the server systems 104 andrepresents a determination of the capabilities of the client systems108, 110 . . . 112. The incentives block 126 is also a subset of theserver systems 104 and represents an incentive provided to the users orowners of the clients systems 108, 110, . . . 112 for allowingcapabilities of the clients systems 108, 110 . . . 112 to be utilized bythe distributed processing system 100. The client systems 108, 110 and112 represent any number of systems and/or devices that may beidentified, organized and utilized by the server systems 104 toaccomplish a desired task, for example, personal computer systems (PCs),internet appliances, notebook computers, servers, storage devices,network attached storage (NAS) devices, wireless devices, hand-helddevices, or any other computing device that has useful capabilities andis connected to a network in any manner. The server systems 104represent any number of processing systems that provide the function ofidentifying, organizing and utilizing the client systems to achieve thedesired tasks.

The incentives provided by the incentives block 126 may be any desiredincentive. For example, the incentive may be a sweepstakes in whichentries are given to client systems 108, 110 . . . 112 that are signedup to be utilized by the distributed processing system 100. Otherexample incentives are reward systems, such as airline frequent-flyermiles, purchase credits and vouchers, payments of money, monetaryprizes, property prizes, free trips, time-share rentals, cruises,connectivity services, free or reduced cost Internet access, domain namehosting, mail accounts, participation in significant research projects,achievement of personal goals, or any other desired incentive or reward.

As indicated above, any number of other systems may also be connected tothe network 102. The element 106, therefore, represents any number of avariety of other systems that may be connected to the network 102. Theother systems 106 may include ISPs, web servers, university computersystems, and any other distributed device connected to the network 102,for example, personal computer systems (PCs), internet appliances,notebook computers, servers, storage devices, network attached storage(NAS) devices, wireless devices, hand-held devices, or any otherconnected computing device that has useful capabilities and is connectedto a network in any manner. The customer systems 152 representscustomers that have projects for the distributed processing system, asfurther described with respect to FIG. 1B. The customer systems 152connect to the network 102 through the communication link 119.

It is noted that the communication links 114, 116, 118, 119, 120 and 122may allow for communication to occur, if desired, between any of thesystems connected to the network 102. For example, client systems 108,110 . . . 112 may communicate directly with each other in peer-to-peertype communications. It is further noted that the communication links114, 116, 118, 119, 120 and 122 may be any desired technique forconnecting into any portion of the network 102, such as, Ethernetconnections, wireless connections, ISDN connections, DSL connections,modem dial-up connections, cable modem connections, fiber opticconnections, direct T1 or T3 connections, routers, portal computers, aswell as any other network or communication connection. It is also notedthat there are any number of possible configurations for the connectionsfor network 102, according to one or more embodiments. The client system108 may be, for example, an individual personal computer located insomeone's home and may be connected to the Internet through an InternetService Provider (ISP). Client system 108 may also be a personalcomputer located on an employee's desk at a company that is connected toan intranet through a network router and then connected to the Internetthrough a second router or portal computer. Client system 108 mayfurther be personal computers connected to a company's intranet, and theserver systems 104 may also be connected to that same intranet. Inshort, a wide variety of network environments are contemplated by one ormore embodiments on which a large number of potential client systems areconnected.

FIG. 1B is a block diagram for information flow 150 among customersystems 152, server systems 104, and client system 134, according to oneor more embodiments. The server systems 104, as discussed above, mayinclude any number of different subsystems or components, as desired,including client system capabilities block 124 and incentives block 126.The server systems 104 send project and benchmark workloads 130 toclient systems 134. A benchmark workload refers to a standard workloadthat may be used to determine the relative capabilities of the clientsystems 134. A project workload refers to a workload for a given projectthat is desired to be completed. The project workload may be, forexample, a workload for projects such as network site content indexing,network site testing including network site load testing and networksite quality of service testing, data back-up, drug design, druginteraction research, chemical reaction studies, bioinformaticsincluding genetic and biological analyses, human genome analyses,pair-wise comparisons including fingerprint and DNA analyses, datamining, Internet hosting services, intranet hosting services, auctionservices, market clearing services, payment systems, bio-informaticsimulations, knowledge management services, trading services, datamatching services, graphics rendering, or any other desired project.

Client systems 134, as discussed above, may be any number of differentsystems that are connected to the server systems 104 through a network102, such as client systems 108, 110 . . . 112 in FIG. 1A. The clientsystems 134 send results 132 back to the server systems 104 after theclient systems 134 complete processing any given workload. Dependingupon the workload project, the server systems 104 may then provideresults 156 to customer systems 152. The customer systems 152 may be,for example, an entity that desires a given project to be undertaken,and if so, provides the project details and data 158 to the serversystems 104.

FIG. 2A is a block diagram for an example client system 108 according toat least one embodiment. In this simplified block diagram, an originalworkload 204 is received through line 208 from an interface 206. Theoriginal workload 204 represents a portion of the processing, storage orother activity required to complete the desired task for which theserver system 104 is trying to accomplish. This original workload 204 issent by the server system 104 through the network 102 and received bythe client system 108 through communication link 118. The client system108 processes the original workload 204. Following line 212, results 202are then stored for transferring along line 210 to interface 206.Interface 206 may then communicate the results back to the server system104 through communication line 118, or to other client systems (forexample, with peering of client systems) and then through the network102.

It is noted that the workload received by client system 108 and theprocessing or activity performed may depend up a variety of factors, asdiscussed further below. In part, this workload allocated by the serversystem 104 to each client system 108, 110 and 112 may depend upon thecapabilities of the client system, such as the processing power, diskstorage capacity, communications types, and other capabilities availablefrom the various components of the systems within the client system 108.

The server systems 104 can select the workloads for the client system108 and may control when these workloads are performed, throughoperational code (i.e., an agent) residing and installed on the clientsystem 108. Alternatively, the owner or user of the client system 108may determine when workloads are procured or obtained from the serversystems 104, as well as when these workloads are performed, for example,by accessing the server systems 104 through the network 102. Forexample, the sever system 104 may download to the client system 108 uponrequest one or more workloads. At the same time, an agent residing onthe client system 108 may operate to process the workload or multipleworkloads downloaded to the client system 108. It is noted, therefore,that the agent may be simultaneously managing more than one workload forany number of projects. When the workload is complete, the agent mayinform the owner or user of the client system 108 the results are readyto be communicated back. The client system 108 may then upload resultsto the server system 104 and download new workloads, if desired.Alternatively, these logistical and operational interactions may takeplace automatically through control of the agent and/or the serversystems 104.

FIG. 2B is a block diagram for processing elements within a clientsystem 108 according to at least some embodiment. In this diagram,client system 108 is contemplated as a personal computer. In a personalcomputer, an internal bus 260 would typically have a variety ofdifferent devices connected to it. For example, a CPU 250 could beconnected through the bus 260 to a 20 video processor 252, a floatingpoint processor 254 (often integrated within the CPU itself), anddigital signal processors (DSPs), such as those found on sound cards andmodems. In addition, any of a variety of other processing devices 258may be included. Furthermore, other types of devices may be connected,such as hard drives 264, which provide disk storage capabilities, and adigital camera 262.

It is noted, therefore, that the capabilities for client systems 108,110 . . . 112 may span the entire range of possible computing,processing, storage and other subsystems or devices that are connectedto a system connected to the network 102. For example, these subsystemsor devices may include: central processing units (CPUs), digital signalprocessors (DSPs), graphics processing engines (GPEs), hard drives(HDs), memory (MEM), audio subsystems (ASs), communications subsystems(CSs), removable media types (RMs), and other accessories withpotentially useful unused capabilities (OAs). In short, for any givencomputer system connected to a network 102, there exists a variety ofcapabilities that may be utilized by that system to accomplish itsdirect tasks. At any given time, however, only a fraction of thesecapabilities are typically used on the client systems 108, 110 . . .112. The present embodiment can take advantage of these unusedcapabilities.

It is also noted that along with receiving the workload, the clientsystem 108 will also receive an agent that manages the completion of theworkload. This agent may be software that is customized for theparticular computer system and processing capabilities of the clientsystem 108. For example, if the client system is a personal computer asshown in FIG. 2B, the agent may be a program that operates in thebackground of the computer's operating system. When the agent determinesthat there is unused processing or other capabilities, the agent maytake advantage of it. For example, if the user is using a wordprocessing application to create a document, little processing power isbeing utilized by the word processing program, leaving the computer'sCPU and video processor underutilized. Thus, the agent could executecommands to these processors during dead cycles. In this way, the agentmay facilitate the completion of workload processing in a reduced time.In addition, this agent may be self-updating upon connecting to theserver systems 104, so that the agent may be kept up to date withcurrent software revisions and workload activities. It is also notedthat the agent may manage work on multiple workloads at the same time,so that any given distributed device connected to the network 102 may beworking on a plurality of workloads at any given time.

FIG. 2C is a block diagram for an example client system agent 270. Theagent 270 may include a security subsystem 272 that controls theinterface of the client system 108 with the agent 270. The securitysubsystem 272 may help keep the workloads secure and may help to keepthe client systems 108 from suffering any security problems incompleting the workload. For example, the agent 272 may operate to keepviruses from attacking the client system 108 while the client system 108is processing the workload through the operation of the agent. Thesecurity subsystem 272, therefore, may provide the interface for theworkloads 130 and the results 132.

The client's system agent 270 may also include a workload engine 274, astatistics/user interface/incentive advertising block 276, and aworkload package and update processing block 278. In the example shownin FIG. 2C, workloads 130 pass through the security subsystem 272 andalong line 280 to the workload package and update processing block 278.In this block 278, the agent 270 may be updated by the server systems104. Alternatively, the agent 270 may determine, when connected to theserver systems 104, whether it should be updated and then accomplishthat updating automatically. Once the workload package is processed, theworkload engine 274 may receive the workload following line 288. Theworkload engine 274 works on the workload, ultimately completing theworkload. The results or status of the workload may then be sent throughthe security subsystem 272 following line 282. The results 132 may thenbe provided back to the server systems 104.

The statistics/user interface/incentive advertising block 276 mayprovide workload, incentive and other statistics, as well as any otherdesired interface features, to the user of the client system. Forexample, the block 276 may show a user the expected amount of processingtime it will take for the client system to complete a workload taskbased upon the capabilities of the system. As also shown, the block 276may receive information following lines 286 and 284 from the workloadpackage and update processing block 278 and from the workload engine274. If desired, security information from the security subsystem 272could also be displayed to the user of the client system. It is notedthat the information displayed to the user of the client system may bemodified and selected as desired without departing from the claimedsubject matter.

With respect to incentive advertising, the block 276 may also show theuser of the client system how this processing time might changedepending upon various possible upgrades to the capabilities of theclient system, such as a faster microprocessor, more memory, more diskstorage space, etc. Furthermore, the client system capabilities may beshown correlated to the incentives provided to the client system forparticipation. Thus, the user may be provided information as to how theuser's incentives would increase or change depending upon other computersystems or upgraded capabilities the user could acquire. This incentivevalue increase may also be tied to upgrades to particular vendor'sdevices. For example, if the user's device is a computer system havingan ABC microprocessor, the block 276 may provide the user information asto increased incentive values based upon an upgrade to a more powerfulABC microprocessor. Similarly, if the user's device is a computer systemobtained from ABC, the block 276 may provide the user information as toincreased incentive values based upon an upgrade to a more powerful ABCcomputer system.

FIG. 2D is an example user interface 276 for a client system agent,including incentive advertising, according to one or more embodiments.In the example shown, interface 276 is a window 230 that may bedisplayed on a distributed device, for example, a computer system. Thiswindow 230 displays the desired information for the agent clientmanager. As indicated above, this agent client manager is initiallydownloaded from the server systems 104 and thereafter may be updated atvarious times when the client system is communicating with the serversystems. The interface 276, as shown, includes interface tabs 221, 222,224, 226, 228, 244, 246, and 248. These interface tabs may be selectedthrough the user of a pointing device or keyboard attached, for example,to a computer system graphically displaying the window 230. It is notedthat the interface tabs 221, 222, 224, 226, 228, 244, 246, and 248 areonly examples, and the number, arrangement and content of tabs may bemodified as desired. In addition, the example user interface 276depicted in FIG. 2D is only an example and may be modified as desired.

In FIG. 2D, the processor values interface tab 224 is the one currentlyselected by the user. The processor values tab 224 includes exampleinformation that may be displayed to the user. Assuming that a workloadis being processed by the agent client manager, the user may select thebutton 242 (Show My Incentive Values) to show the user's currentincentive values associated with the workload being performed. Thepersonal incentive values chart 232 (My Personal Incentive Values) maythen be displayed to the user. As shown, the incentive values areprovided in a relative scale from 1 to 10. The key designation 240represents the incentives associated with the users current centralprocessing unit (CPU) or microprocessor.

As indicated above, this incentive information may also be tied to thespecific vendor of the user's CPU, for example, ABC Company's CPU. Thus,as shown, the key designation 240 (My current processor) and thecorresponding bar graph portion 236 represent incentives for the user'scurrent CPU (e.g., a 166 MHz processor). The key designation 238represents the incentives that the user is projected to have if the userwere to upgrade the CPU. In this manner, a user may be provided anincentive to increase the capabilities of the distributed device, and avendor may be provided advertising so that the user is also directed toa particular upgrade.

Looking further to FIG. 2D, other similar incentive related informationtabs may be provided for any desired capability of the distributeddevice. For example, tab 246 (Memory Values) represents information thatmay be provided for the memory capabilities of the distributed device.Tab 224 (Graphics Values) represents information that may be providedfor the graphics capabilities of the distributed device. Tab 226(Communications Values) represents information that may be provided forthe communication capabilities of the distributed device. Tab 228(Storage Values) represents information that may be provided for thestorage capabilities of the distributed device. Tab 248 (System Values)represents information that may be provided for the system capabilitiesas a whole for the distributed device.

In addition to these incentive related information tabs, other tabs maybe included to provide information and control for any desired featuresof the agent client manager. For example, the tab 244 (Current: PrimeSearch) represents information that may be displayed to the user aboutthe current workload being performed by the agent client manager, forexample, a search for large prime numbers. The tab 221 (Settings)represents information that may be displayed to the user about varioussettings for the client agent manager. In particular, the tab 221 mayprovide the user the ability to control any desired aspect of theoperation of the agent client manager. For example, the user may be ableto select a portion of the capabilities that may be utilized (e.g., amaximum of 20% of the system memory), the types of workloads that may beperformed (e.g., only scientific research projects), the times when theagent may utilize system resources (e.g., only between 12 to 6 am, oronly when the system is idle), or any other desired operational feature.It is noted that in addition to upgrade incentive information indicatedabove, the user may also be provided information as to how incentiveswould increase if the user allocated or changed the settings for theagent client manager.

This user selection of operational features allows for workloads to bescheduled or balanced based upon user input and desires. These uservectors, as indicated above, would allow users to dedicate their devicecapabilities to specific research projects (e.g., cancer, Parkinson'sdisease, Internet, genetics, space science, etc.), to specificnon-profit or for profit organizations (e.g., Greenpeace, Celera, etc.),educational institutions (e.g., University of Texas), a specific groupof likeminded users, or any other entity or endeavor. This affiliationselection allows the distributed processing system to automaticallyinclude a user's device capabilities in a pool dedicated to the chosenaffiliation. Additionally, a user could choose to mix variouspercentages and allocations of device capabilities among multipleaffiliations. It is noted that the user does not have to make anyaffiliation selection and may not allocate 100 percent of devicecapabilities. Rather, only a portion of the device capabilities may beallocated to a particular affiliation, leaving the remaindernon-allocated and not affiliated. The capability allocation may also bea system-wide (i.e., course) allocation, such as some desired percent ofoverall device capabilities. The capabilities allocation may also besubsystem specific (i.e., fine) allocation, such as allocation ofparticular subsystem capabilities to particular affiliations.

Now looking to FIG. 3A, the server systems 104 may be one or morecomputer systems that operate to identify client system capabilities,organize workloads, and utilize client systems to accomplish a desiredtask. The server systems 104 includes a control system 304 a workloaddatabase 308, and a sweepstakes system 306, as discussed more below. Theworkload database 308 stores any desired project task, which may bebroken up into discrete workload tasks WL1, WL2 . . . WLN, asrepresented by elements 336, 338 . . . 340. The workload database mayalso store one or more benchmark workloads (BWL) 335 that may beutilized to determine client system capabilities in response to astandard workload. Through line 312, the workload database 308communicates with control system 304. Control system 304, for example,receives original workload 322 and transfers it to the interface 320through line 330. The interface 320 then transfers the workload 322 tothe network 102 through line 114. This workload 322 is ultimatelyreceived as workload 204 by client system 108, 110 or 112, as shown inFIG. 2A. The result 324 is ultimately received by the control system 304through interface 320 and line 328.

In allocating workloads, the control system 304 may consider thecapabilities of the client systems 108, 110 and 112 to which the controlsystem 304 is sending workloads. For example, if client 108 has moreprocessing power than client 110, the control system 304 may allocateand send more difficult or larger workloads. Thus, client 108 mayreceive WL1 336 and WL2 338, while client 110 would only receive WL3.Alternatively, the workload database 308 could be organized withdiffering levels of processing power or capability requirements for eachworkload. In this way, WL1 336 may represent a greater processing orsystem capability requirement than WL2 338. It should be noted thatworkload may be a processing task, a data storage task, or tied to anyother of a variety of capabilities that may be utilized on the clientsystems 108, 110 . . . 112.

As indicated above, to encourage owners or users of client systems toallow their system capabilities to be utilized by control system 104, anincentive system may be utilized. This incentive system may be designedas desired. Incentives may be provided to the user or owner of theclients systems when the client system is signed-up to participate inthe distributed processing system, when the client system completes aworkload for the distributed processing system, or any other time duringthe process. In addition, incentives may be based upon the capabilitiesof the client systems, based upon a benchmark workload that provides astandardized assessment of the capabilities of the client systems, orbased upon any other desired criteria.

One example use of a benchmark workload is to use the benchmark workloadto determine incentive values. For example, the server systems 104 maybe designed to send out a standard benchmark workload once an hour toeach client system 108, 110 . . . 112. If a client system is notavailable at that time for any reason, the workload would not becompleted by the client system, and there would be no incentive valuegenerated for that client system. In this example, the benchmarkworkload may be a timed work-set that would exercise each subsystem withcapabilities within the client system that was desired to be measured. Amore capable client system would then generate greater incentive valuesfrom executing the benchmark workload, as compared to a lesser capableclient system. These incentive values may be utilized as desired todetermine what the client system should get in return for its efforts.For example, if the incentive were a sweepstakes as discussed furtherbelow, the number of entries in the sweepstakes may be tied to thesystem's performance of the benchmark workload. Thus, the faster orbetter the client system performs the benchmark workload, the moreentries the client system would receive.

In the embodiment shown in FIG. 3A, the server systems 104 may include asweepstakes system 306 that functions with control system 304 to provideincentives for the users or owners of client systems 108, 110 and 112 toallow their system capabilities to be used by the server systems 104.The control system 304 may determine a sweepstakes entry value 302 thatis sent along line 310 to the sweepstakes system 306. The sweepstakessystem 306 may then receive sweepstakes entry 332 and provide it to thesweepstakes engine 330 through line 334. The sweepstakes engine 330 mayprocess the entries and determine a winner, when desired. In theembodiment shown, therefore, entries to the sweepstakes may be generatedeach time a unit of work is accomplished by one or more of thesubsystems within a client system 108, 110 or 112 via an agent installedon the device for the purposes of managing and completing units of work.The total entries for any period of time would, therefore, be dynamicdepending on how many are received. Odds of winning would then bedetermined by the total number of entries received and the total numberof entries contributable to any given entrant.

FIG. 3B is another example block diagram of a distributed processingsystem 300 including servers systems 104, customer systems 152, clientsystems 134 and out-sourced host systems 340, according to one or moreembodiments. The servers systems 104 may include an analytic subsystem346, a results/workload production subsystem 344, a projectpre-processing subsystem 342, a client agent subsystem 243, and anincentive advertising subsystem 245. The incentive advertising subsystem245 may operate to provide advertising information, for example, theupgrade incentive information as discussed with respect to FIG. 2D. Theclient agent subsystem 243 may operate to download an agent to theclient systems 134 and to update this agent at times when the serversystems 104 are communicating with the client systems 134.

The customer systems 152, which represent customers that have projectsthat they desired to be processed by the distributed processing system,may be connected to the project pre-processing subsystem 342 to provideprojects to the servers systems 104. These projects are processed by theproject pre-processing subsystem 342 and passed to the results/workloadsproduction subsystem 344, which produces and sends out workloads 130 andreceives back results 130. The analytic system 346 then takes theresults and processes them as desired. Completed project information maythen be provided from the analytic system 346 to the customer systems152. In this manner, the projects of the customer systems 152 may beprocessed and project results reported by the distributed processingsystem in one or more embodiments. Also, as shown, the workloads 130 andthe results 132, or other tasks of the server systems 104, may beprocessed and handled by out-sourced host systems 340, if desired. Thus,some or all of the workloads 130 may be sent first to out-sourced hostsystems 340. Out-sourced host systems 340 then send workloads 130A tothe client systems 134 and receive back results 132A. The out-sourcedhost systems 340 then send the results 132 back to the server systems104. It is noted that this out-sourcing of server system tasks may beimplemented as desired for any given task that the server systems 104may have. It is further noted that, if desired, the server systems 104may perform all of the desired functions of the server systems 104 sothat no out-sourced host systems 340 would be used.

FIG. 3C is a block diagram for one embodiment of a server systemprocessor 350, according to one or more embodiments. An agentabstraction layer 360 may send workloads 130 and receive results 132.The security subsystem 354 may interact with the agent abstraction layer360 and provide information to a data parser 352 and an applicationprogramming interface (APIs) block 356. The APIs block 356, the dataparser 352 and a workload manager 558 may interact to accomplish thedesired tasks for the server system processor 350. It is noted that forthis embodiment, the API protocol could be controlled and provided toother host systems.

FIG. 3D is an alternative block diagram for a server system processor350, according to one or more embodiments. In this embodiment, the APIsblock 356 and the agent abstraction layer 360 are not present. The dataparser 352, the workload manager 358 and the security subsystem 354interact to provide the desired server system tasks. It is noted thatfor this embodiment, the security subsystem is controlled and utilizedfor communicating with client systems.

FIG. 4 is a functional block diagram for a sweepstakes operation 400 bythe system server 104 according to an embodiment. In block 402, theserver systems 104 may sign-up client systems in “accept clients” block402. Following line 418, the server systems 104 identify thecapabilities of the client's computer and processing systems in the“determine client system capabilities” block 404. Control passes alongline 420 to the “distribute workloads to client systems” block 406,where the server systems 104 allocate workloads to each client system108, 110 and 112. This workload may also be a benchmark workload, asindicated above, that acts as an entry workload to determine the entriesor entry values for the client system. As also indicated above, indistributing the workloads in block 406, the server system 104 may takeinto consideration the capabilities of the client systems to whichworkloads are being distributed. The client systems 108, 110 and 112then operate to complete the workloads allocated to them. The serversystem 104 receives back workload results in “receive workload results”block 408.

At this point, control passes along line 424 to the “determinesweepstakes entries” block 410. In this block 410, the server system 104determines the entry value for the workload completed or for a standardbenchmark or entry workload completed. This entry value may be weightedupon a variety of factors including factors such as the amount of workcompleted, the difficulty level of the processing required, and theaccuracy of the results. It is noted that any desired weighting may beutilized. Thus, it is understood that a wide variety of considerationsmay be utilized to determine the entry value weighting for thesweepstakes.

Although the weighting determination is shown in block 410 in FIG. 4,the entry value may also be determined, in whole or in part, when aclient system signs on to the distributed processing distributed systemof one or more embodiments. For example, if a client system hasstate-of-the-art CPU, video processor, DSP engine, memory, and largeamounts of free disk storage space, a high entry value may be allocatedto this client system up-front. In contrast, a client system that has aslow CPU, a weak video processor, no DSP engine, little memory, andlittle free disk storage space may be allocated a small entry value. Inthis way, the owners or users of the client systems may be providedimmediate feedback as to the potential sweepstakes entry value of theircomputer systems, devices and system capabilities.

It is further noted that the entry value may take any desired form andmay be, for example, a multiplier that will be used for each unit ofworkload completed. In this way, the owner or user will readily becognizant that a state-of-the-art system will yield a high multiplier,where as an older system, system capability or device will yield a lowmultiplier. Such feedback, whether communicated to the owner or userimmediately upon signing up or upon completion of each workload, willcreate an incentive for owners and/or users to acquire state-of-the-artsystems, thereby further increasing the potential processing power ofthe distributed processing system of one or more embodiments. Inaddition, different workload projects may be designated with differententry values, as well. For example, some workload projects may requireparticular hardware or software processing systems within a clientsystem or device. Thus, the number of client systems that are capable ofperforming the task would be limited. To further encourage participationby those owners or users with capable systems, the entry value fortaking on particular workloads and/or systems with the desired featuresmay be allocated higher entry values.

Referring back to FIG. 4, control passes along line 426 to the “processentries” block 412. In this block 412, the sweepstakes entries areprocessed and stored as desired. Following line 428, “end of entryperiod” decision block 414 represents a determination of whether thetime for getting entries into the sweepstakes has ended. If not, thecontrol continues to line 430 and back to blocks 402, 404 and/or 406,depending upon what is desired. Once the entry period has ended, controlflows along line 432 to “determine winners” block 416. The server system104 then identifies from among the entries, who the winning clientsystem or systems will be.

The entry period may be any desired time frame and may include multipleoverlapping time frames, as desired. For example, winners may bedetermined daily for entries each day, monthly for entries within amonth, and/or yearly for entries within one year. In addition, specialentry periods may be generated, if desired, for example where aparticularly important workload project had a short time frame in whichit is to be completed.

FIGS. 1A-B, 2A-C, 3A-D, and 4 are directed to example embodiments for adistributed processing system according to one or more embodiments,including a sweepstakes reward or incentive feature, as shown in theembodiments of FIG. 3A and FIG. 4.

FIGS. 6A and 6B further describe a capabilities scheduling feature, inwhich the server systems 104 may identify and consider any of a varietyof client system capability vectors in determining how to organize,allocate and manage workloads and projects. FIGS. 5A and 5B describe adistributed processing system and workload project that accomplishesnetwork site indexing. FIGS. 7A and 7B describe a distributed processingsystem and a workload project that accomplishes network site testing,such as quality of service (QoS) testing and load testing. And FIG. 8describes a distributed processing system with respect to a corporateintranet that accomplishes distributed data back-up.

FIG. 9 is an alternative representation for the interconnection fabricfor a distributed processing system environment and describes idleclient system identification and shared component client systems. FIG.10 describes a client system agent installed on a client system. FIGS.11A and 11B further describe machine generated sweepstakes entries.FIGS. 12A and 12B describe client capability selection features. FIGS.13A and 13B describe data conversion services. FIG. 14A describes adistributed processing system that provides data transmission 20caching. FIG. 14B describes a distributed processing system thatprovides data sharing and file distribution functions. And FIG. 15describes an alternative representation for a distributed processingsystem, according to one or more embodiments.

Looking now to FIG. 5A, block diagram is depicted of a distributedprocessing system 550 for a network site indexing application, accordingto one or more embodiments. As stated above with respect to FIG. 1A, thenetwork 102 may be a wide variety of networks. For this network siteindexing application, the network 102 may be the Internet having amultitude of network sites 552 . . . 554. Each network site 552 . . .554 may have a variety of different content types that may be indexed,ranging from complex sites to relatively simple sites. For example,network site 552 includes text 570A, images 570B, audio streams 570C,video streams 570D, files 570E and other content 570F. Network site 554is less complex and includes text 572A, images 572B, and other content572C. Both network sites 552 and 554 are connected to the network 102through communication lines 558 and 556, respectively.

As discussed above, the server systems 104 manage workloads for theclient systems 108, 110 . . . 112. The client systems 108, 110 . . . 112process these workloads and produce indexing results. The resultingindex may be stored at a centrally managed site, such as central indexstorage block 560, or may itself be distributed over the possiblymillions of indexing clients 108, 110, . . . 112, as shown by remoteindex storage blocks 562, 564, . . . 566. If remote index storage isutilized, a master database content index may be stored locally, forexample, in the central index storage block 560. This content index maythen direct relevant searches to the distributed massively parallelengine for search queries.

Referring now to FIG. 5B, a functional block diagram is shown for anetwork site indexing operation 500 according to one or moreembodiments. As described in FIG. 1A with respect to other systems 106,there may be any number of computer and processing systems connected tothe network 102. Any one of these others systems 106 may publishinformation on the network 102 for access by any other system connectedto the network 102. This information to be indexed may take a widevariety of forms, including, for example, text, images, audio streams,video streams, databases, spreadsheets, PDF files, Shockwave data, Flashdata, applications, data files, chat streams, or any other information,data or data streams that may be accessible on a network site. Thedistributed processing system of one or more embodiments may have as aworkload the task of indexing this potentially massive amount ofinformation.

For example, where the network 102 is the Internet or a large intranet,a large amount of processing power and time can be used to create anaccurate, complete and up-to-date index of the information. The Internetuses an IP (Internet Protocol) address protocol to direct traffic aroundthe Internet. The IP address is the address of a computer attached to aTCP/IP (Transmission Control Protocol/Internet Protocol) network. Everysystem on the network must have a unique IP address. IP addresses aretypically written as four sets of numbers separated by periods. TheTCP/IP packet uses 32 bits to contain the IP address, which is made upof a network and host address (NETID and HOSTID). The more bits used fornetwork address, the fewer remain for hosts. Web pages within aparticular web site with a unique address may be addressed through URLs(Uniform Resource Locator) associated with that web site. In short,there is a limited, but very large, number of possible IP addresses foruniquely identifiable Internet sites that may be accessed and analyzedto generate an index of Internet sites and web pages via URLs.

The operation diagram of FIG. 5B starts with the “clients receiveindexing workloads” block 502. In this block, the system server 104provides the clients systems 108, 110 . . . 112 with a workload task toindex a portion of the information accessible on the network 102. Forexample, with the Internet, each workload may be single EP address orgroups of URLs or, in some cases, large data types contained on singlesites or pages. Following line 514, the “clients interact with othersystems” block 504 represents the operation of the agent installed onthe client systems 108, 110, . . . 112 to access the network sites,according to the assigned workload, and index the information accessibleon that site. This indexing may include all types of informationaccessible on that site, including text, audio, image, video, etc.

Next, following lines 516 and 518, the client systems 108, 110, and 112completes the workload tasks, get the results ready for transmission,and sends those results back to the system server 104 in “clientscomplete workload” block 506 and “indexing results sent to serversystem” block 508. Control passes along line 520 to “index compiled foruse” block 510 where the server system formats and/or compiles theresults for use. For example, the index results may be utilized foraccurate, complete and up-to-date search information for the network102. As indicated with respect to FIG. 5A, the resulting index may bestored remotely or locally following line 522. Thus, element 524represents remote storage of the index and element 526 representscentral storage of the index. It is noted that the index may also bestored with a mixture of central and remote storage, as desired. Inaddition, as indicated above, a directory or summary index for theresulting index may be generated and stored centrally, if desired. It isfurther noted that the summary index may be stored in any other desiredfashion, for example, it may be distributed and stored on a number ofclient systems.

FIG. 6A is a block diagram for a server system 104 according to anembodiment, including a control system 304, a workload database 308, anda database of capability vectors 620. The workload database 308 includesa variety of sets of workload projects WL1, WL2 WLN. For each workloadproject, there may be multiple workload units. For example, workloadproject WL1 includes workload units WL11, WL12 . . . WL1N, asrepresented by elements 640, 642 . . . 644, respectively. Similarly,workload project WL2 includes workload units WL21, WL22 . . . WL2N, asrepresented by elements 646, 648, . . . 650, respectively workloadproject WL3 includes workload units WL31, WL32 . . . WL3N, asrepresented by elements 652, 654 . . . 656, respectively.

It may be expected that different workload projects WL1, WL2 . . . WLNwithin the workload database 308 may require widely varying processingrequirements. Thus, in order to better direct resources to workloadprojects, the server system may access various system vectors when aclient system signs up to provide processing time and other system ordevice capabilities to the server system. This capability schedulinghelps facilitate project operation and completion. In this respect, thecapability vector database 620 keeps track of any desired feature ofclient systems or devices in capability vectors CBV 1, CBV2 . . . CBVN,represented by elements 628, 630 . . . 632, respectively. Thesecapability vectors may then be utilized by the control system 304through line 626 to capability balance workloads.

This capability scheduling according to one or more embodiments,therefore, allows for the efficient management of the distributedprocessing system. This capability scheduling and distribution will helpmaximize throughput, deliver timely responses for sensitive workloads,calculate redundancy factors when appropriate, and in general, helpoptimize the distributed processing computing system of one or moreembodiments. The following TABLE 1 provides lists of capability vectorsor factors that may be utilized. It is noted that this list is anexample list, and any number of vectors or factors may be identified andutilized, as desired.

TABLE 1 Example Client Capability Vectors or Factors 1 BIOS Support: a.BIOS Type (brand) b. ACPI c. S1, S2, S3, and S4 sleep/wake states d. Dl,D2 and D3 ACPI device states e. Remote Wake Up Via Modem f. Remote WakeUp Via Network g. CPU Clock control h. Thermal Management control i.Docked/Undocked state control j. APM 1.2 support k. Hotkey support l.Resume on Alarm, Modem Ring m. Password Protected Resume from and LANSuspend n. Full-On power mode o. APM/Hardware Doze mode p. Stand-by modeq. Suspend to DRAM mode r. Video Logic Power Down s. HDD, FDD and FDCPower Down t. Sound Chip Power Down u. Super I/O Chip Power Down 2 CPUSupport: a. CPU Type (brand) b. MMX instruction set c. SIMD instructionset d. WNI instruction set e. 3DNow instruction set f. Other processordependent g. Raw integer performance instruction set(s) h. Raw FPUperformance i. CPU LI data cache size j. CPU Ll instruction cache sizek. CPU L2 cache size 1. CPU speed (MHz/GHz . . . ) m. System bus(MHz/GHz . . . ) speed supported n. Processor Serial Number o. CPUID 3Graphic Support a. Graphics type (brand) b. # of graphics engines c.Memory capacity d. OpenGL support e. Direct3D/DirectX support f. Colordepth supported g. MPEG VII decode assist h. MPEG1/II encode assist i.OS support j. Rendering type(s) supported k. Single-Pass Multitexturingsupport l. True Color Rendering m. Triangle Setup Engine n. TextureCache o. Bilinear/Trilinear Filtering p. Anti-aliasing support q.Texture Compositing r. Texture Decompression s. Perspectively CorrectTexture Mapping t. Mip-Mapping u. Z-buffering and Double-bufferingsupport v. Bump mapping w. Fog effects x. Texture lighting y. Videotexture support z. Reflection support aa. Shadows support 4 StorageSupport a. Storage Type (brand) b. Storage Type (fixed, removable, c.Total storage capacity etc.) d. Free space e. Throughput speed f. Seektime g. User dedicated space for current workload h. SMART capable 5System a. System Type (brand) b. System form factor (desktop, portable,workstation, server, etc.) 6 Communications Support a. Type ofConnection (brand of ISP) b. Type of Connection Device (brand c.Hardware device capabilities of hardware) d. Speed of connection e.Latency of connection f. Round trip packet time of g. Number of hops onconnection type connection h. Automatic connection support i. Dial-uponly (yes/no) (yes/no) j. Broadband type (brand) k. Broadband connectiontype (DSL/Sat./Cable/T 1/Intranet/etc.) 7 Memory a. Type of memory errorcorrection (none, ECC, etc.) b. Type of memory supported (EDO, c. Amountof total memory SDRAM, RDRAM, etc.) d. Amount of free memory e. Currentvirtual memory size f. Total available virtual memory size 8 OperatingSystem a. Type of operating system (brand) b. Version of operatingsystem c. Health of operating system 9. System application software a.Type of software loaded and/or operating on system b. Version ofsoftware c. Software features enabled/disabled d. Health of softwareoperation

FIG. 6B is a functional block diagram for capabilities determination andscheduling operation 600 for workloads in a distributed processingsystem according to an embodiment. Initially, various vectors areidentified for which capability information is desired in the “identifyclient system capability vectors” block 602. Following line 612, theserver systems 104 then capability balances workloads among clientsystems 108, 110 and 112 based upon the capability vectors in the“capability scheduling workloads based on vectors” block 604. Then thecapabilities scheduled workloads are sent to the client systems 104 forprocessing in the “send capability scheduled workloads” block 606.

This capability scheduling and management based upon system relatedvectors allows for efficient use of resources. For example, utilizingthe operating system or software vectors, workloads may be scheduled ormanaged so that desired hardware and software configurations areutilized. This scheduling based upon software vectors may be helpfulbecause different software versions often have different capabilities.For example, various additional features and services are included inMICROSOFT WINDOWS 98® as compared with MICROSOFT WINDOWS '95®. Any oneof these additional functions or services may be desired for aparticular workload that is to be hosted on a particular client systemdevice. Software and operating system vectors also allow for customersto select a wide variety of software configurations on which thecustomers may desire a particular workload to be run. These variedsoftware configurations may be helpful, for example, where softwaretesting is desired. Thus, the distributed processing system of one ormore embodiments may be utilized to test new software, data files, Javaprograms or other software on a wide variety of hardware platforms,software platforms and software versions. For example, a Java programmay be tested on a wide proliferation of JREs (Java Runtime Engines)associated with a wide variety of operating systems and machine types,such as personal computers, handheld devices, etc.

From the customer system perspective, the capability management and thecapability database, as well as information concerning users of thedistributed devices, provide a vehicle through which a customer mayselect particular hardware, software, user or other configurations, inwhich the customer is interested. In other words, utilizing themassively parallel distributed processing system of one or moreembodiments, a wide variety of selectable distributed device attributes,including information concerning users of the distributed devices, maybe provided to a customer with respect to any project, advertising, orother information or activity a customer may have to be processed ordistributed.

For example, a customer may desire to advertise certain goods orservices to distributed devices that have certain attributes, such asparticular device capabilities or particular characteristics for usersof those distributed devices. Based upon selected attributes, a set ofdistributed devices may be identified for receipt of advertisingmessages. These messages maybe displayed to a user of the distributeddevice through a browser, the client agent, or any other software thatis executing either directly or remotely on the distributed device.Thus, a customer may target particular machine specific device or userattributes for particular advertising messages. For example, users withparticular demographic information may be targeted for particularadvertisements. As another example, the client agent running on clientsystems that are personal computers may determine systems that aresuffering from numerous page faults (i.e., through tracking operatingsystem health features such as the number of page faults). High numbersof page faults are an indication of low memory. Thus, memorymanufactures could target such systems for memory upgrade banners oradvertisements.

Still further, if a customer desires to run a workload on specificdevice types, specific hardware platforms, specific operating systems,etc., the customer may then select these features and thereby select asubset of the distributed client systems on which to send a projectworkload. Such a project would be, for example, if a customer wanted torun a first set of simulations on personal computers with AMD ATHLON®microprocessors and a second set of simulations on personal computerswith INTEL PENTIUM III® microprocessors. Alternatively, if a customer isnot interested in particular configurations for the project, thecustomer may simply request any random number of distributed devices toprocess its project workloads.

Customer pricing levels for distributed processing may then be tied, ifdesired, to the level of specificity desired by a particular customer.For example, a customer may contract for a block of 10,000 randomdistributed devices for a base amount. The customer may later decide foran additional or different price to utilize one or more capabilityvectors in selecting a number of devices for processing its project.Further, a customer may request that a number of distributed devices bededicated solely to processing its project workloads. In short, oncedevice attributes, including device capabilities and user information,are identified, according to one or more embodiments, any number ofcustomer offerings may be made based upon the device attributes for theconnected distributed devices. It is noted that to facilitate use of thedevice capabilities and user information, capability vectors and userinformation may be stored and organized in a database, as discussedabove.

Referring now to FIG. 12A, a block diagram depicts a distributedprocessing system 1200 that allows customers to select client systemattributes, such as device capabilities and user characteristics,according to one or more embodiments. In this embodiment, the network102 is depicted as the Internet to which server systems 104, customer152A, customer 152B, and client systems 1202A, 1202B . . . 1202C areconnected. These systems are connected through communication links 114,119A, 119B, 1204A, 1204B . . . 1204C, respectively. As noted above,these communication links may include any of a wide variety of devicesand/or communication techniques for allowing a system to interface withother connected systems.

As shown in FIG. 12A, and as discussed above, the customers 152A and152B may desire to send information or projects, such as advertisements(ADV) 1206A and 1206B and/or projects (PROJ) 1208A and 1208B, to groupsof client systems that have particular or selected capabilities. Thenumber of different groups of client systems is as varied as thecapability and user data available for those client systems. The clientsystems 1202A represent client systems that include a first set (Set 1)of desired attributes. The client systems 1202B represent client systemsthat include a second set (Set 2) of desired attributes. And the clientsystems 1202C represent client systems that include a Nth set (Set N) ofdesired attributes. Once attributes are selected, the client systemswith those attributes may be accessed as desired by customers 152A 20and 152B. For example, customer 152A may send its advertisement toclient systems 1202B. Customer 152B may send its advertisement to clientsystems 1202A. The project 1208A from customer 152A may be processed byclient systems 1202C. And the project 1208B from customer 152B may beprocessed by client systems 1202B. It is noted, therefore, that anycombination of desired attributes, such as device capabilities and usercharacteristics, may be identified and utilized to satisfy customerobjectives, whether those objectives be advertising, project processing,or some other desired objective.

FIG. 12B is a block flow diagram for client system attribute selection,according to one or more embodiments. In the embodiment shown, process1250 begins with the customer selecting desired attributes in block1252. Next, client systems with selected attributes are accessed inblock 1254. And, then in block 1256, the customer objective, such asadvertising or project, is processed by the client system. Control ofthis process 1250 may be provided by the server systems 104, if desired,such that the customer interfaces with the server systems 104 to selectdevice attributes and then the servers systems 104 access the clientsystems. Alternatively, the server systems 104 may simply provide thecustomer with a list of contact information (e.g., IP addresses) for theclient systems, so that the customer may directly access the clientsystem, for example, in providing advertisements to the users of theclient systems. It is further noted that other control techniques mayalso be used to identify and access client systems with particulardesired device capabilities, user characteristics, or other deviceattributes, according to the client system attribute selection method ofone or more embodiments.

FIG. 7A is a block diagram for a network 102 according to one or moreembodiments, including example network sites 106A and 106B on which sitetesting is to be conducted, such as load testing and/orquality-of-service (QoS) testing. FIG. 7A is similar to FIG. 1A exceptthat other systems 106 in FIG. 1A has been represented in the embodimentof FIG. 7A with network sites 106A and 106B. Communication line 116Abetween the network 102 and the network site 106A represents ainteraction by one client system 108, 110 and 112. Communication lines116B, 116C and 116D represent interactions by more than one clientsystem 108, 110 and 112.

Site testing is typically desired to determine how a site or connectedservice performs under any desired set of test circumstances. With thedistributed processing system of one or more embodiments, siteperformance testing may be conducted using any number of real clientsystems 108, 110 and 112, rather than simulated activity that iscurrently available. Several tests that are commonly desired are siteload tests and quality of service (QOS) tests. Quality of service (QOS)testing refers to testing a user's experience accessing a network siteunder normal usability situations. Load testing refers to testing what aparticular network site's infrastructure can handle in userinteractions. An extreme version of load testing is a denial-of-serviceattack, where a system or group of systems intentionally attempt tooverload and shut-down a network site. Advantageously, one or moreembodiments will have actual systems testing network web sites, asopposed to simulated tests for which others in the industry are capable.

Network site 106B and the multiple interactions represented bycommunication lines 116A, 116B and 116C are intended to represent a loadtesting environment. Network site 106A and the single interaction 116Ais indicative of a user interaction or QOS testing environment. It isnoted that load testing, QOS tests, and any other site testing may beconducted with any number of interactions from client systems desired,and the timing of those interactions may be manipulated and controlledto achieve any desired testing parameters. It is further noted thatperiodically new load and breakdown statistics will be provided forcapacity planning.

FIG. 7B is a functional block diagram for a site-testing operation 700according to one or more embodiments. Initially, client systems 108, 110and 112 receive workloads that identify testing procedures andparameters in the “clients receive testing workload” block 702.Following line 714, the client systems 108, 110, and 112 access the sitebeing tested and perform the testing in block “clients interact withother systems” block 704. Next, following lines 716 and 718, the clientsystems 108, 110 and 112 complete the site testing workload tasks, getthe results ready for transmission, and send those results back to thesystem server 104 in “clients complete testing workload” block 706 and“site testing results sent to server system” block 708. Control passesalong line 720 to “site testing results compiled for use” block 510where the server system formats and/or compiles the results for use bythe network site. For example, the site testing results may be utilizeddetermining modifications that are to be made to the network site tohandle peek volume activities.

FIG. 8 is a block diagram for a distributed processing system 800 for adata back-up system application, according to one or more embodiments.As stated above with respect to FIG. 1A, the network 102 may be a widevariety of networks, including an intranet network. Intranet networks,such as internal networks set up by corporations, are particularlysuited for this application because the systems holding the data beingbacked-up would be owned by the same entity owning other systems withexcess data storage capabilities. In this way, security would not be asgreat of an issue and the client system types could be bettercontrolled. It is noted, however, that this data back-up applicationwould be equally applicable to other networks, such as for computersystems connected through the Internet.

Referring back to FIG. 8, client systems 108, 110 . . . 112 are showneach having backup data blocks 804, 806 . . . 808. Customer systems 152is shown as having data 802, which is desired to be backed-up with thedistributed back-up system 800. The server systems 104 manage the flowof data from the data 802 and the client systems that have extra storagespace represented by back-up data blocks 804, 806 . . . 808. Inoperation, the server system 104 identifies client system storagecapabilities. With this information, the server systems 104 can receivedata for back-up from any system on the network 102. It is noted, and asindicated with respect to FIG. 1A, the client systems 108, 110 . . . 112and the customer systems 152 may communicate directly with each other inpeer-to-peer type communications.

The servers systems 104 may also manage the storage and transfer of dataso that the data will be readily retrievable once backed-up and storedon the client systems 108, 110 . . . 112. If desired, a summary index ordirectory of the backed-up data may be stored centrally on the serversystems 104, or may be stored remotely on the client systems 108, 110 .. . 112. It is also noted that the server systems 104 may alsodistribute data back-up workloads so that each portion of the data 802is stored redundantly on at least two of the client systems 108, 110 . .. 112. This redundancy provides added security should any one or moreclient systems suddenly cease to be operational.

Looking now to FIG. 9, a block diagram is depicted of an alternativerepresentation of an interconnection fabric for a distributed processingsystem environment 100, according to one or more embodiments. In thisdiagram and as described above, the network environment may be theInternet, an internal company intranet, a local area network (LAN), awide area network (WAN), a wireless network, a home network, or anyother system that connects together multiple systems and devices. Inaddition, the server systems and clients systems may be interconnectedby a variety of possible connection interfaces, for example, Ethernetconnections, wireless connections, ISDN connections, DSL connections,modem dial-up connections, cable modem connections, direct T1 or T3connections, fiber optic connections, routers, portal computers, as wellas any other network or communication connection. It is noted,therefore, as discussed with respect to other embodiments such as theembodiment of FIG. 1A, that systems may be coupled into aninterconnected fabric in any of a variety of ways and communications canpotentially occur directly or indirectly between any of the systemscoupled into the fabric, as would be understood by those of skill in theart.

Within this environment, as depicted in FIG. 9, server systems 104 areinterconnected with any number of client systems, for example, clientsystems 108A, 108B, 108C, 108D, 108E, 108F, 108G, 108H, 108I, 108J,108K, and 108L. In addition, these client systems may also include idleclient systems 902A, 902 B, and 902C, as discussed further below.Furthermore, these client systems may include client system 904A with acomponent A, client system 904B with a component B, and client system904C with a component C. It is also noted that the interconnectionfabric may include any number of devices that are not client systems, inthat they themselves are not providing components or processingcapabilities for the distributed processing 20 system of one or moreembodiments. Nevertheless, these devices may be considered part of thesystem because they may relay, interpret, process or otherwise transmitor receive information from or to client systems that are part of thedistributed processing system.

Aggregation of component level resources, according to one or moreembodiments, will now be discussed. As described above, the capabilitiesof client systems are determined for purposes of allocating, schedulingand managing distributed processing workloads. In other words, each ofthe client systems may be made up of many individual subsystems withvarious capabilities. In some cases, it may occur that particularcomponents on different machines may provide added value if combined oraggregated. Thus, utilizing subsystem or component level resources froma heterogeneous group of devices may be the most efficient or otherwiseadvantageous way of taking advantage of these resources to completevarious desired tasks.

Referring now more particularly to FIG. 9, the client systems 904A,904B, and 904C may have component A, component B and component C,respectively, that are better utilized in combination. For example,client system 904A may have a fast processor, a high-speed networkconnection, but little available storage space. Client system 904B mayhave large amounts of available free storage space but little processingpower. Client system 904C may also have a fast processor, but relativelylittle available storage space. In this example, a workload thatrequires both a large storage capacity and a fast processor may beefficiently completed by dedicating component level resources to variousparts of the workload from different machines. Thus, the workload may bemanaged by having client systems 904A and 904C processing data stored onand transmitted from client system 904B. Once clients systems 904A and904C process data, this resulting data may then be transmitted back toclient system 904B for aggregation and eventual transmission back to theserver systems 104. The client system 904B, therefore, essentially actsas a server for a workload subset, sending out portions of a subsetworkload, receiving back the processed data, and aggregating the data tobuild a completed workload subset.

It is noted that any number of different components from differentclient systems may be aggregated, as desired. For example, for wirelessdevices, DSP processing and storage components could be aggregated withcomponents from other client systems. For display devices, graphicsrendering power could be aggregated. For relatively dumb machines, suchas connected household appliances, vending machines, etc., slow-speedprocessing components could be aggregated. In short, an appropriateworkload may include instructions to numerous client systems that willenable collaboration and aggregation of component level resources. Suchinstructions may include things, such as, where to receive input, whereto send output, and ultimately which client systems return finalresults.

It is further noted that the control instructions may be de-centralizedas well. In other words, as indicated above, client systems maycommunicate directly with each other, for example, in a peer-to-peerfashion. In this way, workload communications may occur directly betweenclient systems, and workload control and management may occur throughthe client system agents located on client systems.

Still referring to FIG. 9, idle system determination will now bediscussed. As stated above, client system capabilities are determinedand utilized within the distributed processing system of one or moreembodiments. The more time any particular client system is idle, themore processing it is arguably able to accomplish, and the moreincentives it is likely to receive. In other words, the client systemcapabilities may be utilized more often and more intensely if the clientsystem is idle more frequently. As such, it is advantageous to identifyidle client systems and allocate them to more processor and timesensitive tasks. By identifying these idle client systems, resourcesavailable on the network at any given time may be more fully utilized,and otherwise idle resources may be utilized for highly intensive,real-time activities that would otherwise require dedicated devices.Examples of such real-time activities include data caching, indexing,etc. In FIG. 9, idle client systems are designated as 902A, 902B, and902C.

Identifying idle resources may be determined in any of a variety ofways. It is possible, for example, to simply look at whether a machineis not being used or has low processor utilization at any given time.This simple determination, however, may not yield an accurate picture ofhow idle a client system may or may not be over a given time period.More particularly, discovery methods may be implemented to identify theactivity of a variety of client system components and subsystems. Forexample, subsystems may be monitored, such as network activity, deviceoutput activity, user input, processing activity, executing taskmonitoring, or mode of operation parameters (e.g., mobile or powermanagement modes, stationary or powered mode). In addition, any numberof other device vectors may be monitored or analyzed to determine thetrue usage and idleness of a client system.

The following TABLE 2 provides a list of idleness vectors or factorsthat may be utilized in determining the level of device usage oridleness. In particular, TABLE 2 provides two primary categories ofactivities to monitor or analyze for determination of how idle a clientsystem may or may not be. These activities are user activity and deviceactivity. By monitoring, analyzing, and tracking these client systemelements and activities over time, a better determination of deviceusage and idleness may be made. It is noted that the list provided inTABLE 2 is an example list, and any number of categories, vectors orfactors may be identified and utilized, as desired, according to one ormore embodiments.

TABLE 2 Example Client Idleness Vectors or Factors 1 User Activity(e.g., monitor input a. keyboard input activities, monitor outputactivities, monitor time elapsed since last input event and betweeninput events, etc.) b. mouse input c. microphone/voice input d. tabletinput e. pen input f. touch screen input g. joystick input h. gamepadinput i. video output j. printer output k. any other user activity thatcould be utilized to classify if a device is idle 2 Device Activity(e.g., monitor a. power state (e.g., time since last utilization levels,monitor time elapsed power state change event) since last deviceactivity, monitor time between changes in device utilization levels,etc.) b. mobility state (e.g., time since c. screen saver activity ortrigger (e.g., device last in mobile state) time elapsed sincescreensaver activity or trigger) d. screen output (e.g., time elapsed e.network or communication packets since last screen output, paint eventsent or received (e.g., time elapsed or pixel change) since last networkor communications activity) f. storage device activity (e.g., time g.processor, DSP, microcontroller, elapsed since last storage deviceembedded device, or other activity, such as hard drives, flash processoractivity (e.g., time elapse memory cards, removable drives, CD sincelast processor activity) drives, DVD drives, etc.) h. processor, DSP,microcontroller, i. tasks or processes executing (e.g., embedded device,or other processing time elapsed since change in number deviceutilization (e.g., change in of tasks or processes executing)utilization levels) j. task or process device utilization k. any otherdevice activity that could (e.g., time since change in task or be usedto classify if a device is idle process device utilization)

As a further example of the usefulness of this determination, referenceis made back to FIG. 9. Server systems 104 may have, for example, alarge, intensive task that it would like to place on these idle devices.After using a number of the vectors in TABLE 2 to determine theutilization level for client systems, the server systems 104 determinesthat client systems 902A, 902B, and 902C are idle and capable ofhandling significant time sensitive processing tasks. For example, idleclient systems 902A, 902B and 902C may be personal computers that canact as a local interne cache for other connected devices, such as someof the other client systems depicted in FIG. 9, that are interested in adata type that benefits from a local network cache.

Thus, data or content may be transmitted from a remote network site tothe idle machines 902A, 902B, and 902C. These idle devices 902A, 902B,and 902C may then re-transmit this same data or content to otherconnected devices also interested in the data or content. One examplefor such network caching is Internet video or multimedia broadcastevents that are desired to be viewed or received by a very large numberof geographically close connected devices• at about the same time. Inorder to meet the demand of these connected devices, web sitesbroadcasting an event have to be able to handle a huge increase innetwork traffic over a short period of time. By locally caching thetransmission to idle client systems, a web site can reduce the directdemand on its own resources. This is so because other connected devicesmay receive a re-transmitted broadcast, although delayed, from the idleclient system. It is noted that according to one or more embodimentsidle client systems 902A, 902B and 902C may work independently or incombination. Even though idle client systems are suited for providingthe caching function, it is also noted that that network caching may beaccomplished using one or more client systems regardless of theirrespective levels of idleness.

FIG. 10 is a more detailed block diagram for a client system agent 270installed on a client system, according to one or more embodiments. Thisdiagram includes a security subsystem 1010, a capabilities subsystem1006, a workload processor 1004, a user interface 1002, and a projectmanagement and agent control subsystem 1008. The various components andsubsystems may communicate with each other, for example, through lines1012, 1014, 1016, 1018, and 1020. Externally, the client system agent270 may communicate through its security subsystem 1010 with the othercomponents within the client system and ultimately to other devicesconnected into the network fabric. It is noted that configuration of theclient system agent and its operation, both internal and external, maybe selected and designed, as desired. As depicted, the capabilitiessubsystem 1006 includes an idle system monitor 1022, as described above,that monitors and analyzes user and device activities associated withthe client system to determine the level of activity or idleness for theclient system. The information determined by this idle system monitor1022 may then be communicated externally, for example, through thesecurity subsystem 1010 to the server systems 104. The server systems104 may then store and analyze system idleness data from across thedistributed processing system. This idleness data may become part of thecapabilities database that is utilized to allocate and manage workloadsand processing system resources.

Still referring to FIG. 10, the workload processor 1004 includes amachine entry generation subsystem 1024. As described above, theworkload processor 1004 may send completed workloads back to serversystems 104 to generate sweepstakes entries for the host client system.In this way, when the incentive is a sweepstakes, the client system maygenerate entries by completing workloads. The machine entry generationsubsystem 1024 refers to this entry generation through workloadcompletion. As discussed above, the workload processed to generateentries may be a project workload, an entry workload, or any otherworkload, as desired.

FIGS. 11A and 11B provide more detailed flow diagrams of processembodiments for machine generated sweepstakes entries through processingof entry workloads, according to one or more embodiments.

Looking first to FIG. 11A, an entry workload process flow 1100 isdepicted that provides machine generated sweepstakes entries. Processmoves from start block 1102 to block 1104 in which entry workloads areloaded on client systems. Next, process flows to block 1106 whichrepresents a periodic timer or other timing control for entry workloadprocessing. After this timing control, the client system executes orprocesses the entry workload in block 1108. In block 1110, a sweepstakesentry is thereby generated and returned to the server system 104 basedupon the completion of this entry workload. Process control then mayproceed back to the periodic timing block 1106, where timing controldetermines when the entry workload is next processed. The completedworkload represents the machine generated sweepstakes entry.

FIG. 11B is an alternative entry workload process flow 1150. The processflow 1150 is similar to the process flow 1100 except that the entryworkload is sent to the client system each time it is to be run. Processstarts in block 1102 and passes to the periodic timer block 1106, inwhich the process is controlled. For example, server systems 104 maydetermine when it is desirable for the client systems to receive andprocess an entry workload. In block 1104, the entry workload is sent tothe client systems. As with FIG. 11A, the client systems then executethe entry workload in block 1108, and an entry is generated and returnedto the remote server systems 104 in block 1110. The process thenproceeds back to the periodic timer 1106 until it is determined thatanother entry workload should be processed. The primary differencebetween process 1150 and process 1100 is that process 1150 is depictingan entry workload that is transmitted to the client system each time itis to be run. One example utilizing the process 1150 or the process 1100is for servers systems 104 to query the client systems for entryworkload processing at regular time intervals. If a distributed devicereturns a completed entry workload back within a selected period of timefrom the distribution of the entry workload, the server system mayconclude that the distributed device should receive an entry because thedistributed device is providing resources to the distributed processingsystem. In this way, the server systems 104 may determine at regularintervals whether a given client system is working on project workloadsfor the distributed processing system. Alternatively, the client systemagent may locally control the workload processing and may, for example,cause the client system to process and generate entries at regular timeintervals. It is noted that non-regular and varying time intervals mayalso be utilized and that combinations of remote and local control mayalso be utilized, as desired.

The timing of when a client system processes the entry workload,therefore, may be determined locally by the client system agent orremotely, for example, through commands sent by the server systems 104.In addition, periodic timing control may also be accomplished throughvarious combinations of control routines residing locally and remotely.It is further noted that any number of different variations may beutilized to provide machine generated entries to a sweepstakes,according to one or more embodiments. Thus, a client system may generatesweepstakes entries in any of a variety of ways and still have machinegenerated sweepstakes entries, according to one or more embodiments.

FIGS. 13A and 13B describe a data conversion application 1300 for amassively parallel distributed network according to one or moreembodiments. In particular, FIG. 13A is a block diagram of a distributedprocessing system that provides data conversion services, according toone or more embodiments. And FIG. 13B is a block flow diagram for dataconversion services within a distributed processing system, according toone or more embodiments.

Converting file types, web pages, graphics images, etc., between devicetypes can be a highly intensive processing task. Example devices thatoften use converted data are wireless devices, such as pagers and cellphones, that request Internet web page information from their respectivedevice servers. The device server, instead of incurring the overhead ofreformatting the requested data for the wireless devices, may insteaddistribute the requested page or data address, the device typeinformation of the requesting device, and return address for thereformatted data. According to one or more embodiments, the dataconversion, translation or processing may be performed by a clientsystem of the distributed processing system of one or more embodiments.The resulting data may then be returned or provided to the originalrequesting device. In addition to data formatting for cell phones,language conversion, text translation and media translation services, orany other desired data conversion can also be hosted for a customerthrough the distributed processing system of one or more embodiments.

It is noted that the data conversion operation contemplated by one ormore embodiments is not limited to any particular requesting device, anyparticular service provider, any particular type of data to beprocessed, any particular type of resulting processed data, or anyparticular data source. Thus, the data processed may include voice,text, application, image, source code, or any other data type orcombination of data types, and the resulting processed data may alsoinclude voice, text, application, image, or any other data type orcombination of data types. According to one or more embodiments, thedistributed processing system is utilized to process any data that isdesired by a requesting device and that must be converted or processedbefore being provided to the requesting device. For example, an end-userdevices connected to the Internet, such as personal computers, may signup for data conversion services through the server system so that theend-user device may request data conversion of any desired data, file,web site content, etc. Language translations and data formatting forconnected wireless are just two examples of such applications for one ormore embodiments.

Looking now to the embodiment of FIG. 13A, the network 102 is depictedas the Internet, and the requesting device is one or more wirelessdevices 1306 connected to the Internet 102 through communication links1308 and to the wireless device server systems 1304 throughcommunication link 1309. The data to be converted, translated orotherwise processed is represented by block 1302 and may be, forexample, content from an Internet web site that is connected to theInternet through communication link 1312. Also, as shown in FIG. 13A, amassively parallel distributed network (MPDN) server 104 is connected tothe Internet 102 through communication link 114. The wireless deviceserver systems 1304, or any other connected system that desires tooff-load data conversion processing requirements (e.g., web site contentservers), are connected to the Internet 102 through communication links1310 and to the MPDN server 104 through communication links 1311. Anynumber of client systems 108, 110, 112 may also be connected to theInternet 102, through communications links 118, 120 . . . 122,respectively. As also stated above, any of the connected devices maycommunicate with each other in any of a wide variety of communicationtechniques (e.g., wireless, electrical, digital, analog, light-based,etc.) and protocols (e.g., static or dynamic EP addresses), and throughany number of other devices, as would be understood by one of skill inthe art.

In the application contemplated by FIG. 13A, the wireless devices 1306at times request data, for example, images or text from a web site, thatmust be converted, translated or otherwise processed by wireless deviceserver systems 1304 before it can be transmitted to, and displayed on, arequesting wireless device. Instead of converting the information, thewireless device servers systems 1304 may request that the MPDN server104 accomplish the data conversion or translation. The device serversystems 1304 may then provide to the MPDN server 104 any pertinentinformation, such as information concerning the requesting device, thenature of the data requested, and the processing utilized for the data.The MPDN server 104 may then utilize one or more of the client systems108, 110 . . . 112 to process the data from block 1302 for transmissionto the requesting device. In this way, the wireless device serversystems 1304 may off-load burdensome and process-intensive conversiontasks to the distributed processing system of one or more embodiments.

It is noted the transmission of processed data to the requestingwireless device 1306 may occur in a variety of ways. For example, theprocessed data may be transmitted from a client system 108 to the server104, then to the wireless device server 1304 and finally to the wirelessdevices 1306. Alternatively, the processed data may be transmitted froma client system to the wireless device server 1304, and then to thewireless devices 1306. Still further, the processed data may betransmitted directly from a client system to the wireless devices.

FIG. 13B provides a basic flow diagram for an embodiment of a dataconversion process 1350 according to one or more embodiments. In block1352, a device, such as wireless devices 1306, requests unconverted,non-translated or non-processed data. In block 1354, a server for thedevice, such as wireless device server systems 1304, processes the datarequest and contacts the MPDN server 104. In addition, the contentprovider or server for the requested data, such as a web site contentserver, may contact the MPDN server 104. The wireless device serversystems 1304 provide all pertinent information to the MPDN server 104,such as the type of calling device, its identification, the relevantdata requested, and the conversion to take place. The MPDN server 104then distributes the data and information concerning the requestingdevice to one or more client systems, such as client systems 108, 110 .. . 112, in block 1356. The one or more client systems then convert,translate or otherwise process the data in block 1358. The converted,translated or processed data is then provided to the requesting devicein block 1360. Again, in this way, the device servers may provide a widerange of information without having to provide itself the processingpower to accomplish the conversion, translation or processing that isrequired to transmit or display the data on a requesting device.

As shown in FIG. 13B, the device server or the content server 1304 maycommunicate data and other pertinent information for a conversiondirectly to the client systems. For example, the MPDN server 104 mayprovide access to a group of client systems for data conversion purposesfor given periods time (e.g., monthly client group allocations), or mayprovide identities of groups of client systems that may be used at thetime a conversion is to be used. Once the identity and allocation ofclient systems to a particular device server or content server is made,the device server or content server may communicate directly with theclient systems. In addition, the device server or content server mayprovide directly to a requesting device the identity of the one or moreclient systems accomplishing the data conversion. As shown in FIG. 13B,the requesting device, therefore, may communicate directly with theclient system or systems to provide pertinent information concerning thedata conversion requested. The client system may then, for example,directly download the desired content and perform the desired dataconversion. It is further noted that in addition to the embodimentsdescribed above with respect to FIGS. 13A and 13B, other methods forrequesting, processing and providing data to and from the requestingdevice may be implemented with distributed processing system of one ormore embodiments, such as caching processed data for later transmission.

FIGS. 14A and 14B depict example block diagrams of file distribution anddata sharing through the network fabric, according to one or moreembodiments. In particular, FIG. 14A depicts an Internet data filedistribution system 1400 that relies upon client systems to providelocal data distribution. FIG. 14B depicts a data file distributionsystem 1450 that allows for data sharing and rapid transmission of aproject or data files through the distributed processing system.

Looking now to FIG. 14A, a block diagram is depicted of a distributedprocessing system 1400 that provides data transmission caching or otherlocal distribution, according to one or more embodiments. In theembodiment of FIG. 14A, server systems 104 are connected throughcommunication link 114 to the Internet back bone 1402. The Internet backbone 1402 represents the very high speed connections that carry datalong distances, for example, T3 or fiber optic lines that carry Internetdata across the United States. A web site 1404 is connected to theInternet back bone 1402 through communication link 1406, whichrepresents a geographically local connection. The connection block 1410represents a geographically remote communications link, such as a POPserver, head-end machine, telephone line central office, cell site, etc.This communications block 1410 is connected to the Internet back bone1402 with a communications link 1408, which also represents ageographically local connection. A variety of client devices andnon-client devices 1412A, 1412B, 1412C, 1412D, 1412E and 1412F may beconnected below the connection block 1410. It is noted that interface1414 represents, for example, a secondary network on which clientdevices 1412D, 1412E and 1412F are connected, such as a home network.

In the embodiment shown in FIG. 14A, web site 1404 may provide contentthat is in high demand, over a short period of time. An example of suchan event is a live Internet multimedia broadcast. For such an event,there may be a huge influx of devices trying to download the contentfrom the web site 1404 over a short period of time. The web site 1404may be unable to meet this extremely large demand, requiring the website 1404 to shut down.

According to one or more embodiments, the web site 1404 may off-loadsome or all of its data handling requirements by using the distributedprocessing system for data caching. The web site 1404 may contact serversystems 104 and request data caching services. The server systems 104may then identify a local machine, such as client device 1412E, to actas a local distributor of the content for web site 1404. For example,one or more idle client devices that have been identified, as discussedabove, may be utilized as local distributor client device 1412E. Thelocal distributor client device 1412E may first download the content andpass it on to other client and non-client devices 1412B, 1412C, and1412D through communication links 1416A, 1416B, and 1416C. It is notedthat this caching will be aided if the client and non-client devicesreceiving the cached data are relatively short communication hops fromlocal distributor client device 1412E.

This data or network caching allows data to be streamed to an end userlevel device, which may then pass the data on to other end user devices.Thus, the downstream communications may be limited, thereby taking thedistribution burden off of the web site. For example, web site 1404 mayhave a large streaming video or multimedia file that is experiencing aheavy load from a given set of network devices. This data file may becached by a machine, such as client device 1412E, that is below from acommunication link 1410. Then, other devices that are also below thiscommunication link 1410 may download the streaming video data from theclient device 1412E. This caching can eliminate repeatedly sending thesame data through the same communication links to requesting devicesthat are located below common communication links. It is noted that thefile and data distribution possibilities for this peer file access,caching and data transmission, according to one or more embodiments, arewide and varied and should not be seen as limited to the embodimentshown in FIG. 14A.

FIG. 14B is a block diagram of a distributed processing system 1450 thatprovides data distribution and data sharing, according to one or moreembodiments. As with FIG. 9, FIG. 14B depicts an alternative view of anetwork fabric that may interconnect any of a wide variety of devices.In the embodiment shown in FIG. 14B, server systems 104 areinterconnected with any number of client systems 108A, 108B, 108C, 108D,108E, 108F, 108G, and 108H. Each of the connecting interconnectsrepresents any of a wide variety of communication links that may existbetween devices in the network fabric of one or more embodiments. Eachof the client systems 108A, 108B, 108C, 108D, 108E, 108F, 108G, and 108Hinclude shared data (SD) according to one or more embodiments. Withinthis interconnected fabric, block 1452 represents data or projectinformation that is desired to be distributed. The SD blocks within eachclient system facilitates the distribution of this data or projectinformation.

A client agent, as discussed above, installed on the client systems108A, 108B, 108C, 108D, 108E, 108F, 108G, and 108H includesfunctionality that facilitates a number of services with respect to datatransmission and sharing. First, the client agent provides a protecteddata storage area accessible to outside devices, which is represented bythe SD block within each client system in FIG. 14B. This special storagespace protects the device from outside devices accessing other storageareas on the device while allowing data to be shared and accessed byother devices and simultaneously used by the local client agent.

These shared data (SD) blocks provide mechanisms that enable a widevariety of possible interactions among the client systems 108A, 108B,108C, 108D, 108E, 108F, 108G, and 108H. For example, the data sharingmechanism may provide a space for a cache of other device addressesattached to the network for both communication purposes as well assecurity purposes. The mechanism may also provide a simple indexingsystem that is automatically re-indexed when content is added or removedfrom the storage area. This indexing system may provide a mechanism forother client agents to perform discovery on the local client informationand vice versa. Through information stored within this shared data, thedistributed processing system of one or more embodiments facilitatesmany distributed file system applications such as distributed resumeposting, distributed caching, distributed advertisement serving, etc. Inaddition to the above, the storage block (SD) within each client systemmay include an interface for displaying or playing data types (such asimages, audio files, video fifes, etc.) stored both locally and/orremotely on other client devices. This would enable simple picturesharing, for example, between remote families connected via theInternet, as part of being a client system within the distributedprocessing system of one or more embodiments.

In the embodiment shown in FIG. 14B, data or project 1452 is injectedinto the fabric through a connection to client system 108C and serversystems 104. These connections represent that the information may passfirst to servers systems 104, or may pass first to a client system, suchas client system 108C. It is noted that there are other ways that thedata may be injected into the fabric. Once injected, the data 1452 maybe transmitted throughout the fabric through any of a wide variety ofcommunications, including client-to-client, server-to-client,client-to-server, client-to-non-client, non-client-to-clientcommunications, and/or non-client-to-non-client communications. Thesecommunications may be based upon a variety of mechanisms, such aspolling mechanisms and pre-assigned firewall ports. This techniqueprovides a vehicle that facilitates the distribution of information to alarge number of devices in a short period of time.

Applications for this data distribution are wide a varied. For example,a file that is time sensitive may be propagated to a large number ofclient devices, non-client devices, servers, or other connected devices,in a short amount of time. This transmission may occur quickly andefficiently once the information is injected into the distributedprocessing system of one or more embodiments. Example time sensitivedata files are anti-virus signature files, which when distributedthrough the distributed processing system of one or more embodiments,may be transmitted through the network fabric faster than a new virusmay normally proliferate.

Another application for rapid propagation of files is utilizing thistechnique for propagation of workloads. One example is distributedresume or job searching. In such a system, participating job seekers andparticipating employers may rapidly search for one another. A job seekermay inject a job request or search into the fabric that is then routedby each successive device to other devices without control from theserver systems 104. Similarly, an employer may inject candidate criteriainto the fabric that is then routed to successive devices. The result isan extremely fast search and identification of employers and candidates.

FIG. 15 is a block diagram of an alternative representation for adistributed processing system 100, according to one or more embodiments.Server systems 104, database systems 1546, and web interface 1554 arecoupled together through communication links 1540, 1542, and 1544. Theweb interface 1554 includes client's subsystem 1548, task developersubsystem 1550, and advertiser's subsystem 1552, and may include othersubsystems as desired. The database systems 1546 include workload (WL)information 308, client capability vector information 620, and any otherstored information as desired. Server systems include various modulesand subsystems, including database interface 1532, web server 1536, taskmodule and work unit manager 1530, client statistics module 1534,advertising manager 1538, task module version/phase control subsystem1528, sweepstakes engine 1524, server control subsystem 1526, andcommunication interface 1522. It is noted that in the embodiment of adistributed processing system 100 as depicted in of FIG. 15, the threeprimary operations for the server systems 104, database systems 1546 andweb interface 1554 are directed to managing, processing and providing aninterface for client systems, customer tasks, and customer advertising.

As discussed above, each client system includes a client agent thatoperates on the client system and manages the workloads and processes ofthe distributed processing system. As shown in FIG. 15, each of theclient agents 270A, 270B . . . 270C communicates with the server systems104 through communication links 1516, 1518 . . . 1520, respectively. Asdiscussed above, any number of different techniques and architecturesmay be utilized to provide these communication links. In the embodimentas shown in FIG. 15 with respect to client agent 270A, each client agentincludes a base distributed processing system component 1506 and aseparate project or workload component 1504. As depicted, acommunication interface 1508, a core agent module 1502, and a userinterface 1510 make up the base distributed processing system component1506. The task module 1512 and the work unit 1514 make up the separateproject or workload component 1504. The task module 1512 operates on topof the core agent module 1502 to provide processing of each project workunit 1514. It is noted that different or additional modules, subsystemsor components may be included within the client agent, as desired. Forexample, a personal computer screen saver component may be part of thebase distributed processing system component 1506 or the separateproject or workload component 1504.

Also as discussed above, security subsystems and interfaces may beincluded to provide for secure interactions between the various devicesand systems of the distributed processing system 100. As depicted inFIG. 15, a security subsystem and interface 1560 is interconnected withthe server systems 104, the database systems 1546, the web interface1554, and the client agents 270A, 270B 270C. These interconnections arerepresented by lines 1566, 1564, 1562, and 1568, respectively. Thesecurity subsystem and interface 1560 operates to secure thecommunications and operations of the distributed processing system. Thissecurity subsystem and interface 1560 also represents a variety ofpotential security architectures, techniques and features that may beutilized. This security may provide, for example, authentication ofdevices when they send and receive transmissions, so that a sendingdevice verifies the authenticity of the receiving device and/or thereceiving device verifies the authenticity of the sending device. Inaddition, this security may provide for encryption of transmissionsbetween the devices and systems of the distributed processing system.The security subsystem and interface 1560 may also be implemented in avariety of ways, including utilizing security subsystems within eachdevice or security measures shared among multiple devices, so thatsecurity is provided for all interactions of the devices within thedistributed processing system. In this way, for example, securitymeasures may be set in place to make sure that no unauthorized entry ismade into the programming or operations of any portion of thedistributed processing system including the client agents 270A, 270B . .. 270C.

In operation, client systems or end-users may utilize the client'ssubsystem 1548 within the web interface 1554 to register, set userpreferences, check statistics, check sweepstakes entries, or accomplishany other user interface option made available, as desired. Advertisingcustomers may utilize the advertisers subsystem 1552 within the webinterface 1554 to register, add or modify banner or otheradvertisements, set up rules for serving advertisements, checkadvertising statistics (e.g., click statistics), or accomplish any otheradvertiser interface option made available, as desired. Customers andtheir respective task or project developers may utilize the taskdeveloper subsystem 1550 to access information within database systems1546 and modules within the server systems 104, such as theversion/phase control subsystem 1528, the task module and work unitmanager 1530, and the workload information 308. Customers may also checkproject results, add new work units, check defect reports, or accomplishany other customer or developer interface option made available, asdesired.

Advantageously, the customer or developer may provide the details of theproject to be processed, including specific program code and algorithmsthat will process the data, in addition to any data to be processed. Inthe embodiment shown in FIG. 15, this program code takes the form of atask module 1512 within the workload, while the data takes the form ofwork unit 1514. These two portions make up the project or workloadcomponent 1504 of each client agent 270. For a given project, the taskmodule 1512 will likely remain relatively constant, except for versionupdates, patches or phase modifications, while the work unit 1514 willlikely change each time processing of the data that it represents iscompleted. The project or workload component 1504 runs in conjunctionwith the base distributed processing system component 1506. When adifferent customer or project is started on a given client system, theproject or workload component 1504 will typically be replaced, while thebase distributed processing system component 1506 will likely remainrelatively constant, except for version updates, patches or othermodifications made for the distributed processing system.

Information sent from the servers systems 104 to the client agents 270A,270B . . . 270C may include task modules, data for work units, andadvertising information. Information sent from the client agents 270A,270B . . . 270C to the server systems 104 may include user information,system information and capabilities, current task module version andphase information, and results. The database systems 1546 may hold anyrelevant information desired, such as workload information (WL) 208 andclient capability vectors (CV) 620. Examples of information that may bestored include user information, client system information, clientplatform information, task modules, phase control information, versioninformation, work units, data, results, advertiser information,advertisement content, advertisement purchase information, advertisementrules, or any other pertinent information.

Now looking to FIGS. 16, 17A, 17B, 18A and 18B, an embodiment forsecurity features for the distributed processing of the one or moreembodiments will be described. FIG. 16 provides a representation of thedistributed processing environment including security subsystems. FIGS.17A and 17B provide block diagrams of the communication interfacebetween client systems and the server systems. And FIGS. 18A and 18Bprovide detailed block diagrams of an embodiment of security measuresfor the servers systems and the client systems.

Referring to FIG. 16, an embodiment 1600 of a distributed processingsystem is depicted. Server system 104 includes a security subsystem 354through which communications to and from the server systems 104 may bemade secure. Client systems 108A, 108B . . . 108C and client systems108D, 108E . . . 108F represent any number of client systems that maycommunicate with server systems 104 or with each other. Each of theclient systems 108A, 108B, 108C, 108D, 108E, and 108F include a securitysubsystem 272A, 272B, 272C, 272D, 272E, and 272F, respectively. Theelectronic information 1602 represents information that the serversystems 104 is to communicate to client systems 108A, 108B, 108C, 108D,108E, and 108F in a secure manner, so that no unintended or interceptingrecipient may understand or tamper with the electronic information 1602,and so that no third party may insert non-authorized information intothe distributed processing system 1600. Although not shown, it isunderstood that any one of the client systems 108A, 108B, 108C, 108D,108E, and 108F may have electronic information that is to be securelysent to the server systems 104 or to any other of the client systems108A, 108B, 108C, 108D, 108E, and 108F.

Electronic information 1602 represents information that is communicatedto facilitate the operations of the distributed processing system 1600.Such information includes the client agents that are downloaded to eachclient system, the workload applications for any given workload, and anywork unit that will be processed by a client system. Electronicinformation 1602 may also be any type of information to be sent orreceived within the distributed processing system, such as text, images,audio streams, video streams, databases, spreadsheets, PDF files,Shockwave data, Flash data, applications, data files, chat streams, orany other information, data or data streams. In addition, electronicinformation may be sent by client systems 108A, 108B, 108C, 108D, 108E,and 108F to the server systems 104 and/or any of the other clientsystems.

The Certificate Authority (CA) block 1604 within the server systems 104represents an entity that helps to ensure validity of encryption anddecryption codes. For example, within a public/private key encryptionenvironment, a Certificate Authority may help ensure that a public keyalleged to be from a particular entity is in fact legitimately from thatentity. One third-party entity that performs this CA function on theInternet is VeriSign, Inc. Having a third-party perform the CA functioncan be advantageous in a transaction or communication betweennon-trusted entities. For example, the sending entity provides itspublic key information to the third-party CA, which verifies theinformation and creates a certificate that includes the sending entity'spublic key information. This certificate may then be encrypted andsigned by the third-party CA. The receiving entity may then obtain thecertificate from the third-party CA and decrypt it with the third-partyCA's public key. The receiving party will then have the sending party'spublic key and be fairly secure that it is a legitimate public key fromthe sending party.

As shown in FIG. 16, the CA functionality may be part of the serversystems 104, such that the server systems 104 act as their ownCertificate Authority with respect to client systems 108A, 108B, 108C,108D, 108E, and 108F and any other devices that are part of thedistributed processing system. A third-party CA may not be used as muchin this distributed processing environment because the server systems104 primarily direct the operations of the distributed processingsystem. Thus, a third-party entity may or may not provide a CA function.It is noted that CA functionality may be provided only by the serverssystems 104, only by third-party CAs, or any combination of serversystems 104 and third party CAs, as desired for a particular embodiment.In addition, if desired, no CA functionality could be provided so thatsecure communications between the server systems 104 and the deviceswithin the distributed processing system were conducted without the useof a Certificate Authority.

FIG. 17A is a block diagram of an embodiment 1700 for a communicationinterface between a client system 108 and the server systems 104. Inthis embodiment 1700, the network can be the Internet. As depicted, theclient system 108 includes a client agent 270 and a network browser1702. The server system 104 includes a client agent download site 1710,from which the client system 108 may download the client agent 270through communications 1704. The server system 104 also includes block1718, which represents a variety of client service functions that may beprovided by the web interface for the server systems 104 throughcommunications 1706. For example, in a public/private key securityenvironment, a client system 108 may download from block 1712 aCertificate Authority (CA) certificate that includes the server publickey. In addition, the client system 108 may login to the web pageinterface for the server systems 104. And the server systems 104 maygenerate dynamic certificates. The client system 108 may also send andreceive information to application server 1714 through communications1708, for example, to receive project work units. Finally, as depicted,database systems 1546 may send information to and receive informationfrom the blocks 1710, 1712 and 1714 of the server systems 104 throughcommunications 1716, 1718 and 1720. As discussed more above, databasesystems 1546 may include any desired information, for example, aworkload database 308 and/or a capability vector database 620.

FIG. 17B is a block diagram for an Internet communication protocolstructure 1750 that may be utilized for communications 1704, 1706, and1708. As depicted in FIG. 17B, three basic application layers areutilized by each client system 108 and the server systems 104 tocommunicate with each other. The TCP/IP layer 1756 represents a standardInternet communication protocol that allows devices to identify and sendinformation to each other across the Internet, as is well known to thoseof skill in the art. The secure network layer (SNL) 1754, such as thesecure socket layer (SSL), represents a protocol that allows devices toconfirm the identity of servers and the other devices with whom theycommunicate, as long as those servers or other devices utilize similarprotocols. The application security level 1752 represents other desiredsecurity or communication protocols that are implemented by programsrunning on the client system 108 and/or the server systems 104.

In operation, the server system 104 may secure the download of theclient agent 270 to the client system 108 by requiring that the clientsystem 108 download the client agent 270 from the client agent downloadsite 1710. As part of the server authentication sequence, the downloadsite 1710 will send back an identifier to assure users that they areindeed connected to the proper server systems 104. This identifier maybe, for example, a CA certificate, but may be any other identifier, asdesired. Because it is desirable to have the client agent running on asmany distributed devices as possible for the distributed processingsystem of one or more embodiments, user authentication may not berequired to download the client agent 270 from the download site 1710.

Once a client system 108 has downloaded and installed the client agent270, the client system 108 will communicate with the application server1714 to begin working within the distributed processing system. Forthese communications, server and client authentication may be requiredto help ensure security. To accomplish this authentication, for example,two-way authentication may be utilized. To provide a public/private keycombination for the client agent 20270, each client agent 270 that isdownloaded by a client system 108 may have embedded within its code adefault identifier and a default public/private key pair. Thus, theserver systems 104 may use secure network protocols (such as SSL orsimilar schemes) to authenticate each client system 108, and each clientsystem 108 may use compatible protocols to authenticate each serverapplication with which it communicates. These applications, for example,may include the functionality provided by blocks 1712 and 1714, and,therefore, the communications 1706 and 1708 would utilizeauthentication.

As an alternative to embedding a public/private key combination andassociated identifiers or certificates into the client agent 270, thepublic/private key pairs may be dynamically generated in block 1712. Forexample, at start-up, at reboot or at some desired time or event, theclient system 108 may generate a new public/private key pair. When theclient system 108 next communicates with the server systems 104, theclient system 108 request a certificate from the server systems 104. Theserver systems 104 may then act as a Certificate Authority (CA) andprovide a CA certificate to the client system 108. This dynamiccertificate generation, therefore, allows for added security by allowingeach client system 108 to have its own public/private key pair forsecure network protocol communications and by having this key pairchange at some desired recurring event for the client system 108, suchas reboot.

The client system 108 may initiate communications with the serversystems 104 by logging on to the authentication server, which may bepart of block 1712. The user may be prompted to enter a valid e-mailaddress and/or password, if already registered, or may be asked toregister if the e-mail address and/or password are not recognized. Onceregistration is completed, a password may be e-mailed back to the userto provide validation of the user. If authentication is successful whena user logs into the server systems 104, the server systems 104 mayprovide a host-ID, a user-ID, and a session key for any givencommunication session.

It is also desirable that once a user has successfully registered, theuser may install the client agent 270 on any number of other host oruser systems without interacting with that systems network browser,other than to set host-specific preferences. For example, whendownloaded, the client agent 270 may take the form of a self-extractingprogram that installs appropriate files to the client system 108,including the proper host and user identifications. In addition, to helpensure proper identification, the session keys may be exchanged eachtime the client system 108 communicates with the server systems 104. Forexample, the client system 108 may communicate its current session keyto the server systems 104 each time it communicates with the serversystems 104. The server systems 104 will then send a new session key forthe client system 108 to utilize for the next session. In this way,stale identification information may be reduced. In addition to thissecurity feature, communications may also be encrypted and decryptedwith various encryption techniques, as desired.

Referring now to FIGS. 18A and 18B, one embodiment will be discussed fora security model utilizing public/private key encryption. This securitymodel utilizes a third-party CA to provide a CA certificate for theserver systems 104.

FIG. 18A is a block diagram of an embodiment 1800 for securityprocedures implemented by server systems 104. Electronic information1602 is communicated to a client system 108. This electronic information1602 travels through four different paths that provide securityinformation. One path begins with the electronic information 1602 beingencrypted with the server private key in block 1802. Then, in block1830, the encrypted information is sent to client systems. Thisencrypted information is represented by arrow 1826. A second path flowsfrom block 1802 to block 1804 where a hash value is generated for theencrypted electronic information. It is noted that a hash value is aunique value that may be generated for any given electronic file basedupon the contents of that file and the algorithm used to calculate theunique value. There are any number of algorithms that may be used tocalculate a hash value, as would be understood by one of skill in theart. Proceeding down the second path to block 1806, the hash valuegenerated on the server side for the encrypted electronic information(i.e., the information sent to the client system in 1830 via 1826) iscompared with a hash value 1822 from the client system 108. This hashvalue 1822 represents the client system's calculation of the hash valuefor the encrypted electronic information that the client system 108received from the server system 104. If no tampering has occurred andthe data was transmitted accurately, the client system hash value shouldmatch the server hash value. In block 1808, the server systems 104provide an indication of the result of the hash check evaluation back tothe client system 108. This pass/fail determination is indicated byarrow 1824.

A third path begins with block 1810 where a hash value is calculated fornon-encrypted electronic information 1602. This hash value is thenencrypted in block 1816 with the server private key. Next, thisencrypted hash value is sent to the client system 108 in block 1818. Thearrow 1821 represents the encrypted hash value for the non-encryptedelectronic information. A fourth path, and the last depicted in theembodiment 1800 of FIG. 18A, flows from block 1810 to block 1812, wherethe hash value is partitioned into N different portions. These Ndifferent portions are designated for N different client systems 108, aswell as any client systems 108 receiving a redundant distribution of anyone of the N different portions. In block 1814, the N different hashvalue portions are encrypted with the server private key. Next, the Ndifferent encrypted hash value portions are sent in block 1820 to Ndifferent client systems 108, as well as being sent to client systems108 receiving redundant distributions of the hash value portions. Thearrows 1828 represent the distribution of the N different hash valueportions. It is noted that redundant distribution of the N hash valueportions is desirable because, as discussed below with respect to FIG.18B, when the hash value is reconstructed by a client system 108, it isdesirable to have multiple sources for each portion in case one of thereceiving client systems is not available at any given time.

Looking now to FIG. 18B, the corresponding security proceduresimplemented by client system 108 are discussed. Initially, at block1854, the client system 108 receives CA certificate 1852 containing theserver public key and the server identity. It is again noted that otherunique identifiers may be utilized instead of CA certificates, asdescribed above. If a CA certificate is utilized, this CA certificatemay be provided from a third-party Certificate Authority (CA) or fromthe server systems 104 or any other desired source. In block 1856, theclient system 108 verifies the accuracy of the CA certificate using theCA's public key. If this verification is not successful, the clientsystem 108 may wait some period of time before retrying. In addition,the time period may be a random period of time. In addition, asdiscussed with respect to FIGS. 17A and 17B, the client system 108 willlogin to the server systems 104. If this authentication is notsuccessful in this login, the client system will notify the user of thesystem and the server systems 104, and then wait for some period of timeor a random amount of time before attempting to re-verify.

In block 1862, the client system 108 receives the encrypted information1826. Next, the client system 108 creates a hash value for the encryptedinformation in block 1864. This hash value can be calculated using thesame algorithm utilized by the server systems 104 in generating the hashvalue for the encrypted information in block 1804 of FIG. 18A. Once theclient system 108 has calculated the hash value for the encryptedinformation, this hash value 1822 is sent to the server systems in block1866. As discussed above, a pass/fail response 1824 is sent back by theserver systems 104. This hash check evaluation is received in block1868. If the check was a FAIL, flow passes to block 1870 where theclient system 108 sends out a notice to the server systems 104 and anyother client system to which it is attached that a problem has beenencountered. The client system 108 then ends the current connection withthe server systems 104. It is noted that the client system 108 may retryseveral times before moving onto block 1870, and that the reportingscheme may be modified, altered or developed as desired.

If the hash check evaluation was a PASS, flow passes to block 1872 wherethe electronic information is decrypted with the server public key,which was verified in block 1856. A hash value is then calculated forthe electronic information 1874. Again, the hash generation algorithmcan be the same as that used by the server systems 104 in creating thehash value in block 1810 of FIG. 18A. Next, the hash value is sent fromblock 1874 to block 1886, where it is compared with two other hash valuecalculations. One of the other hash values comes from a path that beginswith block 1858, in which the client system 108 receives the encryptedhash value 1821 for the non-encrypted information. In block 1860, theencrypted hash value is decrypted with the server public key. The hashvalue is then sent to block 1886. The third hash value for block 1886comes from a path that utilizes the N different hash portions sent outby the server systems in block 1820 of FIG. 18A. In block 1876, theclient system receives a portion 1828A of the partitioned hash value1828. In addition to one of the partitioned hash values, it is notedthat the server systems 104 will also send information providing theidentity and source for the N−1 other hash value portions. In block1878, the client system 108 decrypts the portion 1828A with the serverpublic key. Next, in block 1880, the client system 108 resolves theidentity of the source for the N−1 other portions, which may be N1 otherclient systems. In block 1882, the client system 108 obtains the N−1other portions, and assembles the N partitions into a hash value for thenon-encrypted electronic information in block 1884. The resulting hashvalue is then sent to block 1886. It is noted, as indicated above, thatredundant distribution of the N portions of the partitioned hash valueis desirable so that unavailability of one client system will not causeanother client system to be unable to re-assemble the N differentportions.

Once the three hash values are received in block 1886 from threedifferent sources, they are compared to see if they match. If this checkis a FAIL, flow moves to block 1888, where the client system 108 sendsout a notice to the server systems 104 and any other client system towhich it is attached that a problem has been encountered. The clientsystem 108 may also inform the client systems from which it received theN−1 other portions, and the client system 108 may retry the procedures,if desired. In addition, once a client system 108 is notified of apotential problem, the client system 108 may download a special checkfile from the server systems 104 to make sure that the server systemshave not been compromised. If still a FAIL, the client system 108 thenends the current connection with the server systems 104. If the check isa PASS, the electronic information is utilized, as represented by block1890.

FIGS. 19 and 20 provide block diagrams for further describing thedistributed processing system and environment of one or more embodimentsthat allows for third parties, such as network service providers, tomonetize, or gain revenue from, their respective user bases.

Looking first at FIG. 19, a block diagram is depicted for a distributedprocessing system 100 and an environment 1900 in which network serviceproviders are enabled to monetize their user bases. Environment 1900includes a distributed processing system 100, a customer 152, and athird-party network service provider 1902. The customer 152 representsan entity that has a project 1912 that the customer 152 would likeprocessed by the distributed computing system 100. In return forprocessing the project data, the customer 152 will often make a payment1916. The third-party network service provider 1902 maintains a userdatabase 1904 that identifies its user base 1920 including users 1906A,1906B . . . 1906C.

The service provider 1902 may be, for example, an Internet business thatprovides any of a variety of services to users, such as Internet access,e-mail, web page hosting, domain name hosting, file sharing services orany other Internet-based service. In addition, such Internet-basedservices may be offered for free or low cost to users, in which case theusers have historically agreed to view banner or other advertisements inreturn for the free or low cost service. However, as stated above,advertising revenue has been subject to diminished pricing and hasbecome an unreliable source of revenue for many Internet-basedcompanies. To facilitate the number of projects that the distributedprocessing system 100 can take on and the speed at which these projectscan be processed and completed, it is desirable to increase the amountand capabilities of the computing resources available to the distributedprocessing system 100. To the extent that the users of the serviceprovider 1902 represent a pool of underutilized resources, these usersrepresent a potentially valuable resource to the distributed processingsystem 100.

According to one or more embodiments, the service provider 1902 mayrealize value from its user base and thereby monetize this user base byfacilitating the use by the distributed processing system 100 ofcomputing resources related to these users. Thus, for example, in returnfor free services, the users may agree to have their respectivecomputing resources utilized by the distributed processing system 100.The service provider 1902 may then provide to the distributed processingsystem 100 the user identifications (IDs) 1908 related to its user basein return for revenue sharing 1910. This monetizing architecture therebyenables service providers or other entities that control or have userbases with useful processing capabilities, such as Internet-basedservice providers, to generate revenue from its user base, particularlyin the face of falling revenue from other sources, such as advertisingrevenue.

The revenue sharing 1910 may be, for example, a share of payment 1916relative to the amount of processing toward the project 1912 that wascompleted through the use of the user resources 1922 made availablethrough users 1906A, 1906B . . . 1906C. It is noted that the revenuesharing 1920 may take any desired form, including but not limited to (a)upfront payments based upon attributes of the user base, such as size orprocessing capabilities, (b) payments based upon the number of usersthat become members of the distributed processing system, (c) paymentsbased upon the types of projects processed by the user base, or (d) anyother desired compensation scheme related to the value of the user basebeing made available by the third party.

The monetizing method focuses on the capabilities of the Internet,intranet, wireless or otherwise network connected PCs, internetappliances, notebook computers, servers, storage devices, NAS (NetworkAttached Storage), or any other connected computing device that couldprovide any of a number of useful capabilities and that is part of aunderutilized user base, such as user bases of Internet-based businessesthat rely on advertising or any other method of monetizing their userbase in exchange for a valuable service (e.g. free internet access,email, etc.). As discussed above, these useful processing capabilitiesspan the entire range of generic computing subsystems including: CentralProcessing Unit(s) (CPUs), Digital Signal Processor(s) (DSPs), GraphicsProcessing Engine(s) (GPEs), Hard Drive(s) (HDs), Memory (MEM), AudioSubsystem(s) (ASs), Communications Subsystem(s) (CSs), Removable MediaTypes (RMs), or other Add-In/On Accessories (A/OAs) with potentiallyuseful unused capabilities. Market creation and potential compensationfor all unused capabilities can be accomplished through the massivelyparallel distributed software architecture of the distributed processingsystem 100. For example, credits (revenues) would be generated each timea unit of work is accomplished by one or more of the subsystems on auser's computing device via a client agent installed on the device tomanage, process and complete units of work. The total credits/revenuesgenerated may be, for example, dynamic depending on how many arereceived. Through this architecture significant revenues may begenerated from the user base of the service provider where the serviceprovider may have previously been unable to effectively monetize hisuser base.

It is further noted, that entity 1902 may be any entity that has director indirect control over a group of users, such that the user'sresources may be offered to and utilized by the distributed processingsystem 1902. For example, a company with a large group of internal usersthat are linked to the distributed processing system 100 through anintranet network of computer systems or computing devices. The user'scomputing resources may be monetized according to at least oneembodiment.

FIG. 20 is a block diagram representing the components of client agent270 which indicates the various responsibilities for those components.Client agent 270 includes a core agent component 1502, a projectcomponent 1504 and a user interface component 1510. As discussed above,the core agent component 1502 can provide the base distributedprocessing functionality for the client agent 270. The project component1504 can provide the project-specific functionality for the client agent270, and the user interface 1510 can provide any desired user viewableinformation or interaction functionality. These three general componentsmay be modular software components such that the project component 1504,the core agent component 1502, and the user interface component 1510 maybe separate software modules that are linked together throughappropriate APIs (Application Programming Interface). Thus, each ofthese components may be designed and developed independently or jointly,as desired. In effect, the core agent component 1502 can provide abackbone upon which is attached the project component 1504, the userinterface component 1510, and any other desired components. Thus, when anew project or interface is desired for any given client agent 270, forexample, this component may be efficiently replaced with the newcomponent in a modular fashion still utilizing the core agent component1502 as the backbone. In addition, each component may be updated andmodified without requiring modification or updates to the othercomponent's software code.

FIG. 20 also depicts customer 152, distributed processing system (DPS)100, and service provider 1902, which communicate with each otherthrough interactions or interfaces 2012 and 2014. In this embodiment,the customer 152 may provide the software development and code 2002 forthe project component 1504. The distributed processing system 100 mayprovide the core agent code 2008 for the core agent component 1502. Andthe service provider may provide at least a portion of the interfacedevelopment and code 2010 for the user interface component 1510. Inoperation, the workloads 2004 and the results 2006 are typically underthe control of the distributed processing system 100.

It is noted that this modular architecture facilitates the developmentof project and interface software code by entities other than the ownerof the distributed processing system 100. For example, with respect toFIG. 19, an Internet-based service provider may have designed andimplemented a use interface for its user base, such as a web browseruser interface for users of free Internet access services provided bysuch a service provider. Once the core agent component 1502 is installedon a user's computer, the existing third-party user interface may hookinto the core agent component 1502, thereby making the user's resourcesavailable to the distributed processing system 100, while maintainingthe user interface the user has come to expect from the serviceprovider. Thus, the service provider 1902 may provide the user interfaceit desires for the service it is providing, while at the same timemonetizing its user base by facilitating its users becoming part of theavailable resources for the distributed processing system 100.

CONCLUSION

Various embodiments enable a server system to receive a request to storedata, select various distributed devices to store the data, and thensend the data to the selected distributed devices.

Although the subject matter has been described in language specific tostructural features and/or methodological steps, it is to be understoodthat the subject matter defined in the appended claims is notnecessarily limited to the specific features or steps described. Rather,the specific features and steps are disclosed as example forms ofimplementing the claimed subject matter.

1. A method comprising: receiving a request to store back-up data on adistributed processing system from a client system, the back-up datahaving a storage priority; searching a database to identify one or moredistributed devices with excess storage capacity; selecting one or moreof the distributed devices to store the back-up data based in part onthe back-up data's storage priority; sending the back-up data to one ormore selected distributed devices along with retention instructionsindicating conditions for retaining and/or deleting the back-up data;and updating an index with addresses for the one or more selecteddistributed devices that received the back-up data.
 2. A method asrecited in claim 1, further comprising incentivizing one or moredistributed devices to join the distributed processing system, whereinan incentive comprises an authorization to back-up data on thedistributed processing system.
 3. A method as recited in claim 1,further comprising: partitioning the back-up data into N partitionsbased in part on the back-up data's storage priority; identifying Mdistributed devices from the database to store the N partitions; anddistributing the N partitions across the M distributed devices forstorage.
 4. A method as recited in claim 3, further comprising updatingthe index to identify the M distributed devices to which the Npartitions were distributed.
 5. A method as recited in claim 1, furthercomprising identifying at least one workload capability for one or moredistributed devices, and utilizing the at least one workload capabilityto schedule back-up data workloads for the one or more distributeddevices.
 6. A method as recited in claim 1, wherein the storage priorityis configured to enable a determination of a retention time for theback-up data, a recovery speed for recovering the back-up data, and alevel of redundancy for the back-up data.
 7. A method as recited inclaim 6, wherein the retention time, the recovery speed, and the levelof redundancy are used to determine a number of distributed devices tostore the back-up data, and which distributed devices are selected tostore the back-up data.
 8. A method as recited in claim 1, wherein theback-up data includes redundant back-up data so that the back-up data isstored on at least two different distributed devices.
 9. A tangiblecomputer readable medium having instructions stored thereon, theinstructions comprising: instructions to receive a command from a userto store data; instructions to prompt the user to select one or moreoptions for storing the data; instructions to generate a storagepriority for the data based in part on the storage options selected bythe user; instructions to request a server system to store the data, therequest including the data's storage priority; and instructions to sendthe data to the server system for distribution and storage on one ormore distributed devices.
 10. The tangible computer readable medium asrecited in claim 9, wherein the storage priority is configured to enablea determination or a retention time for the data, a recovery speed forrecovering the data, and a level of redundancy for the data.
 11. Thetangible computer readable medium as recited in claim 10, wherein theretention time, the recovery speed, and the redundancy level are used todetermine a number of distributed devices to store the data, and whichdistributed devices are selected to store the data.
 12. A tangiblecomputer readable medium having instructions stored thereon, theinstructions, the instructions comprising: instructions to incentivizeone or more distributed devices to join a network and store data;instructions to receive a request from a client system to store data onthe network, the data having an associated storage priority;instructions to search a database to identify one or more distributeddevices with excess storage capacity; instructions to select one or moredistributed devices to store the data based in part on the data'sstorage priority; instructions to send the data to one or more selecteddistributed devices along with retention instructions indicatingconditions for retaining and/or deleting the data; and instructions toupdate an index with addresses for the one or more selected distributeddevices that received the data.
 13. The tangible computer readablemedium as recited in claim 12, wherein an incentive comprises anauthorization to store data on the network.
 14. The tangible computerreadable medium as recited in claim 12, wherein the storage priority isconfigured to enable a determination of a retention time for the data, arecovery speed for recovering the data, and a level of redundancy forthe data.
 15. The tangible computer readable medium as recited in claim14, wherein the retention time, the recovery speed, and the level ofredundancy are used to determine a number of distributed devices tostore the data, and which distributed devices are selected to store thedata.
 16. The tangible computer readable medium as recited in claim 12,wherein the data includes redundant data so that the data can be storedon at least two different distributed devices.
 17. The tangible computerreadable medium as recited in claim 12, further comprising instructionsto identify at least one workload capability for one or more distributeddevices, and utilize the at least one workload capability to scheduledata workloads for the one or more distributed devices.
 18. The tangiblecomputer readable medium as recited in claim 12, further comprisinginstructions to transfer a software agent to one or more distributeddevices, the software agent configured to manage data sent to the one ormore distributed devices.
 19. The tangible computer readable medium asrecited in claim 12, further comprising: instructions to partition thedata into N partitions based in part on the data's storage priority;instructions to identify M distributed devices from the database tostore the N partitions; and instructions to distribute the N partitionsacross the M distributed devices for storage.
 20. The tangible computerreadable medium as recited in claim 19, further comprising instructionsto update the index to identify the M distributed devices to which the Npartitions were distributed.